Inmagic DB/TextWorks and Vista Virtualization

This post is a follow-up to Peter's post Inmagic WebPublisher PRO and Vista Virtualization, but specifically pertaining to DB/TextWorks. 

I recently had a client who created and added a bunch of records to a new textbase located in a folder under Program Files on her Vista-installed laptop.  When it came time to move the textbase off her laptop onto another computer she zipped up all the textbase files, copied the zip file to her thumb drive and prepared to unzip the files onto the other machine.  With files unzipped on the other machine (an older XP-installed desktop computer), she enthusiastically went to show off her newly created and populated textbase. 

Much to her surprise DB/TextWorks produced a disheartening message indicating that the textbase was empty.  How could this be, she had 170 records in the textbase when it was on her laptop and she had copied every textbase file from the correct folder on her laptop.  I got involved and we looked this way and that way - on both machines - and there was nothing that we could see that could indicate that the textbase could possibly be empty (the .btx, .dbt and .occ files were rather large).

The ah ha moment came when Kathy suggested that Peter had posted something about this on our Blog - back in March 2008 (see above link).  I had skipped over that posting because it had referenced WebPublisher, but in fact it told me exactly what I needed to know.  To change the text and code slightly from what Peter posted:

For instance, say DB/TextWorks indicates that a textbase is located at:

%Program Files%\Inmagic\Textbases

Vista detects that DB/TextWorks does not have permission to save to that location and copies the file to:

%Users%\<your account>\AppData\Local\VirtualStore\Program Files\Inmagic\Textbases

Subsequent read/write operations access the VirtualStore version of the file, even though DB/TextWorks will still think it is accessing the Program Files directory. Poor deluded DB/TextWorks.

It took about 1 minute to find the database files in the VirtualStore location - thank you Peter! - however, there was more, or in this case less, to come!  Two of the essential files were missing.  They were the .tba file and the .sdo file.  Why those two? Who knows?  However, combining the new found files (.acf, .btx, .dbo, .dbr, .ixl, .log, and .occ)  from the VirtualStore location with the .tba and the .sdo file from the presumed location – under Program files, allowed us to complete the textbase and transfer it to another location. 

The lesson learned here:

• On a Vista machine DO NOT install textbases under Program files. 

And a Note: 

• this problem only occurs with Vista's UAC (user account control) turned on.

When distributed transactions go boing: Get Vista, XP, and SQL Server 2000 talking to each other

From XP SP2 and on, all network communication coming out or getting to DTC (Distributed Transaction Coordinator) is disabled by default. For example, if a COM+ object attempts to update a SQL database on a remote computer using a DTC transaction, the transaction fails. Likewise, if your computer hosts a SQL database that components from remote computers try to access using a DTC transaction, their transactions fail. With Vista, it gets even more tightened down (see "Using MSDTC between Vista clients and Windows 2000 servers" for details).

On my development machine, I'm running Vista. As we still do the bulk of our work hooking into SQL Server 2000, I need to run that in a virtual machine; I haven't bothered making all these part of the same domain. Therefore, attempting to do some transactions (via System.Transaction.TransactionScope) makes everything go bonk if you're dealing with a setup like mine:

System.Transactions.TransactionException: The transaction has already been implicitly or explicitly committed or aborted.

And/Or:

The partner transaction manager has disabled its support for remote/network transactions.

And/Or:

MSDTC on server 'servername' is unavailable.

So here's how to make them all play nicely together so you can get back to getting productive work done:

(Caveat: this is for a development environment not production. Obviously, for production environments, you're going to have machines on the same domain, no sign of XP--or Vista for that matter--and can therefore tighten security up quite a bit...make that should tighten security up quite a lot)

1. Enable MSDTC on Vista
   1. Run dcomcnfg (Component Services)
   2. Expand the "Component Services" node, then the "My Computer" node, then the "Distributed Transaction Coordinator" node
   3. Right-click on the "Local DTC" node and select "Properties"
   4. On the "Local DTC Properties", select the "Security" tab
   5. Select Network DTC Access, Allow Inbound, Allow Outbound, No Authentication Required, and Enable XA Transaction
      Note: reduced authentication security required because the machines are not on the same domain (in a production environment, they will be)
   6. Enable service auto start if you so wish:
      1. Run dcomcnfg again if necessary
      2. Locate Distributed Transaction Coordinator and right-click and select "Properties"
      3. In "General" tab, set startup type to "Automatic"
2. Enable MSDTC on XP virtual machine
   1. Run dcomcnfg (Component Services)
   2. Expand the “Component Services” node, then the "My Computer" node
   3. Right-click on "My Computer" and select "Properties"
   4. Select "MSDTC" tab
   5. Click "Security Configuration"
   6. Check/Select "Network DTC Access", "Allow Remote Clients", "Allow Inbound", "Allow Outbound", "No Authentication Required", and "Enable XA Transactions"
   7. Okay your way out after the MSDTC service automatically restarts
   8. Enable service auto start if you so wish:
      1. Open SQL Server Service Manager (SQL Server 2000)
      2. Select Distributed Transaction Coordinator and check "Auto-start service when OS starts."
3. Firewall
   1. On both machines you must add msdtc.exe to your list of exceptions (C:\Windows\System32\msdtc.exe)
   2. You might need to also open port 135. I didn't, but I've heard you might.
4. Run your transaction code to ensure that it works. If not, reboot both machines.

I got the above from a bunch of various blogs, forum posts, and KB articles. Two that were the most helpful were:

• Using MSDTC between Vista clients and Windows 2000 servers
• The partner transaction manager has disabled its support for remote/network transactions

How to install Webpublisher on 64-bit IIS 7

Further to my post called Webpublisher on Windows Vista, here is how to install Inmagic Webpublisher on IIS 7 in a 64-bit environment such as Windows Vista x64 or Windows Server 2008 x64.

These instructions are valid for DB/Text Webpublisher as well as CS/Webpublisher. Steps 1 - 5 are valid for 32-bit IIS 7 as well.

1. Ensure IIS is enabled

This screenshot shows which IIS features are enabled on my Vista x64 machine. The highlighted one is particularly important (IIS metabase and IIS 6 configuration compatibility).

2. Install Inmagic Webpublisher

Follow the usual Inmagic install instructions.

3. Enable ISAPI-dll handler mapping on dbtw-wpd or ics-wpd virtual directory

Open the IIS Manager.

Open the Handler Mappings for the dbtw-wpd or ics-wpd virtual directory. (Figure below shows dbtw-wpd.)

The ISAPI-dll handler is disabled by default.

Enable the ISAPI-dll handler: right-click it, choose "Edit Feature Permissions", and check the "Execute" box. Click OK.

4. Set the Webpublisher dll as an allowed restriction

In the IIS Manager, click on the machine root - this is the top level of the tree in the left column, which shows the machine name. You should see a number of machine-level features, including "ISAPI and CGI Restrictions", as below. If you do not see "ISAPI and CGI Restrictions", you have not properly enabled IIS settings in step 1.

Open ISAPI and CGI Restrictions.

You may see Inmagic Webpublisher as an allowed restriction already. The path will point to the install location of dbtwpub.dll or icswppro.dll, depending on which version of Webpublisher you installed.

If you do not see Inmagic Webpublisher as an allowed restriction, you must add it. (Figure below shows DB/Text Webpublisher.)

5. Create an application pool for Webpublisher

Open Application Pools from the IIS Manager.

Add a new application pool to be used with Webpublisher, called "WebpublisherAppPool".

Go to the dbtw-wpd or ics-wpd virtual directory and open its Advanced Settings. Set the Application Pool to the new WebpublisherAppPool just created.

6. Enable 32-bit applications on the Webpublisher application pool

Open Application Pools from the IIS Manager.

Right-click on WebpublisherAppPool and select Advanced Settings.

Set "Enable 32-Bit Applications" to true. Click OK.

7. Get a drink. You're done.

Whatever drink you like. I like red wine, or on a hot day, gin and tonic.

Some more explanation

Whereas in IIS 6 you could run worker processes in either 32-bit or 64-bit mode, but not both, IIS 7 can run 32-bit and 64-bit worker processes simultaneously. And, as the above instructions make implicitly clear, you can set this behaviour on individual application pools.

Visual Studio and the non-sensical "Apply Cut Copy commands to blank lines where there is no selection" option.

Quoting some comments in Jeff Atwood's "Revinventing the Clipboard" blog post:

What I dislike the most, about the clipboard, is the really bad behaviour in VS. Say you cut something, then you try to past it elsewhere but you hit the C instead of the V (without any text selected) and bravo, you've lost your clipboard content! You now have to undo 3 or 4 times to re-start the manipulation. This is anti-productive at the most.

Fabian on January 22, 2008 03:01 AM

Fabian: That one gets me too, but the good news is that you can turn off that behaviour in Visual Studio.

Go to Tools->Options...->Text Editor->All Languages->General and untick "Apply Cut Copy commands to blank lines when there is no selection"

(I guess this goes towards what Jeff was saying about software having reasonable defaults).

GrahamStw on January 22, 2008 03:10 AM

It's one of those things that I never remember how to reset so here it is. Glory Hallelujah.

And btw, using ClipX and loving it (and yes, the beta seems to work fine in Vista).

Connect to SQL Server Instance on Virtual Machine from Host Machine Running Vista

A couple months back when I first switched my primary developer machine to Vista, I wanted to connect to a SQL Server 2000 instance on my WinXP Pro virtual machine (Virtual PC 2007). It took a bit of digging to figure out how to a) even do it with WinXP to WinXP and then b) do it with Vista as the host OS.

Typically, it's an easy thing to set up your virtual machines to talk to each other, and also talk to the host machine, but to get the host machine to be able to talk to the virtual we need to go a little further by configuring a Microsoft Loopback Adapter. Using the Microsoft Loopback Adapter opens our Virtual Machine only to the host. To do this in Vista, do the following:

1. Install a Loopback Adapter
   1. Open Control Panel
   2. Vista caveat: switch to Classic View to "Add Hardware"
   3. In the "Welcome to the Add Hardware Wizard", click Next.
   4. Select "Install the hardware that I manually select from a list (Advanced)" and click Next.
   5. Scroll down and select "Network adapters" and click Next.
   6. Select under Manufacturer "Microsoft" and then under Network Adapter "Microsoft Loopback Adapter" and click Next.
   7. Click Next and Finish.
2. You can manually configure your IP Address for your adapter, but you can just let the loopback adapter get an auto configuration IP address from your router's DHCP.
3. In your Virtual PC Console, choose settings for the applicable virtual machine, and then choose "Networking".
4. Select the now available "Microsoft Loopback Adapter" (note that your virtual machine will need to be off, not in a saved state, in order to make this change).
5. Turn on your virtual machine and once it's booted up, verify that the Microsoft Loopback Adapter has installed its routing in your host PC's route table by going to a command prompt in the virtual machine and typing "route print".
6. In the case of a virtual machine running WinXP, make sure you've allowed file and print sharing in the virtual machine's firewall settings.
7. Open a command prompt and run ipconfig to find out what your virtual machine's IP address is (note that as we have not configured the Microsoft Loopback Adapter to allow the virtual machine to connect to the outside network, your task bar network icon will warn you that you have limited connectivity – thus the need to run ipconfig from a command line to see if the virtual machine even has an IP address assigned).
8. Check whether your host machine can now communicate with the client virtual machine by pinging it's IP address by opening a command prompt in Vista and typing "ping 169.254.166.12" where you enter your applicable IP address.
   c:\>ping 169.254.166.12
   Pinging 169.254.166.12 with 32 bytes of data:
   Reply from 169.254.166.12: bytes=32 time=1ms TTL=128
   Reply from 169.254.166.12: bytes=32 time<1ms TTL=128
   Reply from 169.254.166.12: bytes=32 time<1ms TTL=128
   Reply from 169.254.166.12: bytes=32 time<1ms TTL=128
   Ping statistics for 169.254.166.12:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
   Approximate round trip times in milli-seconds:
   Minimum = 0ms, Maximum = 1ms, Average = 0ms
9. And voila, you've now successfully networked your host machine to talk with your client virtual machine.

If you still want internet access for your client virtual machine, do the following:

1. Open your Network and Sharing Center
2. Click Manage network connections in the left hand navigation bar
3. Right-click the loopback connection and select properties.
4. In the sharing tab, enable “Allow other network users to connect through this computer's Internet connection.

This "should" work, but I initially encountered "an error occurred while Internet Connection Sharing was being enabled." However, it resolved soon afterwards all by itself.

The article that was the biggest help in getting the above in place was http://www.governmentsecurity.org/archive/t10129.html

UPDATE: Change to post title.

Testing websites that use SMTP email on Vista

Many of the ASP.NET web applications we build use SMTP to send email for one reason or another. Order confirmations, mostly, or selected search results.

Testing code that sends email has always been a pain. We have servers with SMTP service that I could point at from my development workstation, but their various restrictions have been, well, restricting. Nor did I ever like the idea of letting SMTP run openly on my local machine in XP. Not that I had much choice, because a) I had to ensure that the code I wrote followed through with the email send, and b) I wanted to view the email as email to ensure it looked the way it ought.

So along comes Vista with IIS 7. And SMTP is not included. It is included with Longhorn Server 2008 with IIS 7 (apparently), but not Vista. I now no longer have the choice of running SMTP locally. Disaster!

Well, as it happens, I'm fine. I'm better than fine, because I stumbled across a better solution all around. I use a pickup directory location.

Using a pickup directory location lets me specify a folder on my local machine for the email generated by System.Net.Mail. It's not sent anywhere, it's just dumped in that location as a *.eml file which can be viewed by Vista's built-in Windows Mail.

The best thing is, I don't have to change my code in any way to make this happen. I only need to add a snippet to the web.config as follows, identifying the (absolute) directory for pickup:

<system.net>

  <mailSettings>

    <smtp deliveryMethod="SpecifiedPickupDirectory">

      <specifiedPickupDirectory 

pickupDirectoryLocation="v:\inetpub\mailroot\pickup"/>

    </smtp>

  </mailSettings>

</system.net>

I did have to make sure that the ASP.NET worker account, NETWORK SERVICE, had read/write access to that location.
And here's the result. One double-click and I get to see it as it would appear in my inbox:

Probably other developers are like, well *duh*, but this was a new and very pleasant discovery for me.

Public Hotfix Patch Available for Debugging ASP.NET on IIS7

Mentioned first a couple posts back, there is now a public hotfix patch available for debugging ASP.NET on IIS7 that you can download here. The reason for this post is that Scott Guthrie just wrote a post that gives a much better explanation of the problem and fix.

Testing websites locally on Vista Part II

Peter beat me to the post already, but instead of just leaving these thoughts in the comments, I figured I should add my two cents in a dedicated post as there a couple other things to take note of if a) you're not running as an Admin in Vista and/or b) you want to debug easily with Vista and IIS7.

First off, before hitting Peter's post, go to ScottGu's post. It tells you the essential step of making sure you've installed the "IIS 6 Management Compatibility" option within IIS7 (as ScottGu states, it "installs an API for the new configuration system that is compatible with the old Metabase APIs (which is what VS 2005 uses)").

As well, it'll help you if you've continued to run as a non-Admin on Vista with UAC enabled (both Peter and I have given up on this and are running as Admins with UAC off - the horror). I attempted for a month or so to use Vista with UAC etc., but the deal breaker was when I discovered that I couldn't drag and drop files into Visual Studio; nor could I open a project using the sln file. I'll hold off on UAC until stuff like Visual Studio is upped to use it reasonably (however, for those that want to use this as another reason to slam Vista, my love-hate relationship continues, but whenever I have to do something on my WinXP machine, I cringe...thus, there's a whole lot more love right now than hate).

In addition, I've found that in order to enable debugging, I need to add the following two steps:

1. Set your application pool for the site to the Classic .NET AppPool.
2. Enable Windows Authentication so that you can debug the site (haven't taken the time to figure out why this particular combination works, but suffice it to say, out of all the posts out there explaining how to get going with debugging with IIS7, this is the only thing that really matters). You'll get a "Challenge-based and login redirect-based authentication cannot be used simultaneously" alert, but ignorantly ignore this and you'll be fine.

UPDATE: I just found out in the writing of this post, that there is now a Visual Studio patch that fixes the Visual Studio F5 debugging of IIS7Applications on Vista.

NOTE: I LOVE being able to run multiple sites at one time. Bliss!

Testing websites locally on Vista

Now that Vista is here with IIS 7, and can set up multiple websites, I have no more need of the IISAdmin tools I used with Windows XP, which hacked IIS 5 to allow more than one website (the limitation being only one website active at any given time).

I've got a pretty good system going.

1. I set up a website for a client project and assign a host header that resembles the client domain:

2. I open my hosts file (%WINDOWS%\system32\drivers\etc\hosts) and bind the new host header to the local server loopback address:

127.0.0.1     localhost-foo.clientsite.com

3. If I'm working with an ASP.NET website or web application (which is 99% of the time) I tell the Visual Studio 2005 project to use the IIS webserver at the just-defined host header when viewing and debugging:

It all makes for a realistic representation of how the application or website will behave on the client's domain, allowing me to be sure that various relative URLs are going to resolve, for instance. It is often the case that I am working with a predefined website hierarchy and template, so it's important to emulate the client's site as closely as possible, so that deployment is less of a hassle.

How to install Inmagic DB/Textworks on Vista

Right-click on the db/textworks installer. Choose "run as administrator". You may be prompted to proceed and/or enter administrative credentials, depending on your Vista setup. The installer will start installing and should work fine.

If you do not run as administrator, you will get an error like this:

Error 1925. You do not have sufficient privileges to complete this installation for all users of the machine. Log on as administrator & retry installation.

You may be confused by this message if you are logged in as an administrator. Welcome to Vista's User Account Control (UAC).

With UAC, you may have logged in as an admin, but you are not running as one. Instead you are prompted to elevate your permissions whenever you attempt an administrator-level operation. It so happens that Inmagic has not updated db/textworks to handle this scenario and give you fair warning. The error message it gives upon failure is at least completely accurate in its diagnosis, but leaves it up to you to manually elevate your permissions.

Here are some other Inmagic-on-Vista related posts on the Andornot Developer Blog:

• Textbase help won't launch on Vista
• WebPublisher on Windows Vista
• Inmagic WebPublisher web data entry on Vista (IIS 7)
• Inmagic WebPublisher and Vista Virtualization

Virtual PC 2007 and NVIDIA nForce networking conflict on Vista

I have Vista 32-bit on an Intel x86 NVIDIA nForce4 motherboard. Ever since I installed Vista, networking has been... dicey. Any time the computer went to sleep/hibernate, networking would no longer work. Some BSODs on wake. Installing the KB931671 Windows Update reduced the number of BSODs, but not the problem itself.

Updating to the latest nForce4 drivers (15.00, released Feb 5 2007) caused networking to simply stop working from startup. No ethernet, no internet, no connection to other workgroup computers, no ping to gateway even (transmit failed, error code 1231).

Through a process of trial and error, I found that disabling Virtual Machine Networking Services on the nForce Networking Controller, plus netsh interface ipv6 reset from the command line, restored networking. (Virtual Machine Networking Services are installed by Virtual PC 2007 as part of its Virtual Machine Additions.)

So I'm left with no network connectivity on my virtual machines. Perhaps I should count myself lucky I have connectivity on the host, but instead I think, no, a steaming pile of curse words followed by a new NIC will be the answer.

UPDATE June 8, 2007 - Bought a new network card and disabled nVidia networking. All problems resolved. Cost? $35.

Re-partitioning a dual boot Windows Vista and XP system

If you're into adventure on the high seas, extreme blood sports, or are simply a masochist looking for your next hit of sweet, sweet pain, look no further. Have I got an activity for you.

Ladies and gentlemen, I direct your attention to this hard disk. On the C:\ partition, I give you: Windows XP. On the V:\ partition: Windows Vista.

"Hm. V:\ too small, and C:\ very big. I will shrink C:\ and allocate extra space to V:\," says I. Jauntily. I should have paid attention to the flash of green lightning and the ominous thunder-rumble that occurred when I said that. But I did not, and I stand before you now a sadder, but infinitely wiser man.

Here's what I did, minus the cursing and backtracking, minus the time spent on Google and various unhelpful Microsoft KB articles.

1. Back up everything.
2. Get GParted (Gnome Partition Editor) LiveCD, an open source partition manager. Burn to disc. Boot to said disc.
3. Shrink C:\. Extend V:\. Mix, stir, let stand 3 hours.
4. Reboot to Windows Vista install disc. Select "Repair this computer". (It repairs. Quickly.)
5. Reboot, this time to boot manager and to installed version of Vista on V:\. Chkdsk isn't at all sure what the hee-haw you've just been doing and wants to check the disk. Let 'er rip.
6. Log in to Vista. Ta-da. But what about XP? Yeah, it's hooped. (When you try to boot to XP, it says "\ntldr is missing." XP System Recovery Console can't find a Windows XP install, can't map the C:\ partition, can't find its own buttocks with two hands and a flashlight.)
7. While in Vista, download VistaBootPro. It's free. Install. Run.
8. From Manage BCD OS Entries, select Windows XP, or rather, "Earlier Version of Windows". Rename that entry to "Windows XP" while you're at it. Select "Change Boot Drive." Select C: from the dropdown. Apply Updates.
9. Reboot to boot manager and to installed version of XP on C:\. Success!

The above has been a highly condensed version of my experience today. It worked on my machine. Your mileage may vary.

Use Notepad2 in Vista

To use Notepad2 as your default notepad application, follow the instructions found at http://www.mattberther.com/?p=828. Much easier than making things work in XP.

1. Download and extract Notepad2.
2. Rename Notepad2.exe to notepad.exe.
3. Find c:\windows\notepad.exe and c:\windows\system32\notepad.exe and set the owner to ‘Administrators’, and grant Administrators full control.
4. Using Windows Explorer, drag and drop the renamed notepad2.exe to c:\windows and c:\windows\system32.