Since moving to Vista x64 I've had a heck of a time with Oracle clients.  The one thing I could not get working until tonight was ODP with Visual Studio / .NET.  Finally I found a solution.

First, download and install Oracle 11g ODAC and Oracle Developer Tools for Visual Studio. (Link requires registration)   This should get the 32bit stuff installed.   I'm still using an Oracle 10g R2 server.  You will likely need to grab a copy of the TNSnames.ora for your existing client folder and place it in the appropriate tree of the 11g product home.

This however is not enough to get .NET working with ODP.  Go to the folder where you extracted the zip.  We need to find the Oracle.DataAccess.dll.  This can be found in the file named filegroup4.jar, in the stage\components\oracle.ntoledb.odp_net_2.  Winrar will open .jar files if needed.  Extract the Oracle.DataAscess.dll file.

For now, I've put a copy of this file in my projects lib folder.  I then added a reference directly to this file from all projects that need ODP access. 

Keep in mind - before you ship you may want to remove this reference and ensure that the .DLL file doesn't get included in your build.  This should get your Vista x64 box developing with ODP.

To Oracle - come on guys.  Give us some Vista x64 love!

SourceGear recently released a 64 bit native built of the Vault server.  I'm on a real x64 kick lately and really enjoy not seeing *32 beside my processes in task manager.  Vault is one of the best source control providers out there, and you cannot beat the price either.  It is core to my professional life.  Next to Visual Studio - it is one of the most important pieces of software I use. So, did a quick backup of my databases, un-installed the old server and installed the shiny new x64 code.  Problems!

First off, my server was running IIS in 32 bit mode.  This was required to run the previous releases of Vault.  Once the install was complete, I started a dos window and set IIS back to 64 bit:

cscript.exe C:\Inetpub\AdminScripts\adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 0

Then I ran an iisreset.

When I fired up my browser to check the vault service, there was a problem.  All it would display was "Service Unavailable".  At this point, even html files were not being served out.  Did a search on the Sourcegear forums and couldn't find anything.  It's been a long week and I was not firing on all cylinders - so I called up the support team.  (Good thing I renewed my maintenance, oh, this morning =D).  At this point Beth from SourceGear and I brainstormed through the situation and came to the following conclusions:

I was the first customer to call with x64 problems.  Yay for being first!

In IIS Manager, the application pool was disabled.  A check of the event logs showed the following information:

Source: W3SVC-WP

Event ID: 2268

Could not load all ISAPI filters for site/service.  Therefore startup aborted.

This prompted a check the web service extensions.  Sure enough, there was a web service extension there configured for ASP.NET pointing to the 32 Bit assemblies.  I prohibited this extension, and added a new one pointing to the 64 bit aspnet_isapi.dll.  Re-enable the application pool and load a page in the browser - still nothing.

Finally - the last step needed to get everything serving properly was to run the following from the x64 framework folder:

c:\windows\microsoft.net\framework64\v2.0.50727\aspnet_regiis -I -enable

So in summary the following steps should get your Vault server upgraded and running in native x64.  Bear in mind, my server is ONLY running Vault and these steps will break ASP.NET 1.1 applications (and lower) and possibly other code you might have running on the server.

   1: Backup SGVault and SGMaster databases (did I even need to include this?)

   2: Un-install the 32 bit Vault server

   3: Install the 64 bit Vault server

   4: Run cscript.exe C:\Inetpub\AdminScripts\adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 0

   5: Run c:\windows\microsoft.net\framework64\v2.0.50727\aspnet_regiis -I -enable

   6: Start IIS Manager. 

   7: Double check the vault virtual directories to ensure the ASP.NET version is set to v2.0

   8: Prohibit the ASP.Net 32 bit isapi web service extension

   9: Add the ASP.Net 64 bit isapi web service extension

  10: run IISReset.exe

mmmm x64 goodness.  Thanks again to Beth for helping me work through this =)

My configuration is this. I have a 32 bit window server running IIS6 and Mapguide server. however for development purposes and local debugging I needed the web tier to be run from my workstation - but working with my network Mapguide enterprise server.

First off, you need to ensure that IIS 7 is installed on the Vista machine, you also need to specify ASP.NET and the ISAPI components be installed. To start off, run the web tier installation and choose a manual installation. I did a custom install, and did not install the php, site admin, or java components. I installed my web tier to C:\inetpub\MapGuideEnterprise2009. It is critical that you do not install it to the default location in program files (x86), or the Vista permissions will break everything. You will know this has occurred because your map will show all question marks in the layer legend, and no map data.  In the server log you will see session timeout errors.  If you do install it to the default location, just move the entire folder structure out of program files (x86).

Finish the installer, this should deploy the needed mapguide files. I noticed a bit of a delay in the copying new files portion of the installer. Seemed to be hung for several minutes, but it did complete.

Now start up IIS manager (start / run / inetmgr)

This is the 'hard' part. It looks nothing like what I was expecting.  IIS Internet Manager has been pretty static for the past, oh ten years...

A default web site should be configured - double click on the computer in the left pane to expand the tree.

First off - we're going to create a new application pool specifically for Mapguide. This will save us some problems down the road. If you are not familiar with them, application pools are a newer concept introduced in IIS 6. Each application in IIS requires an application pool. Only one version of the .NET framework can be used by a single application pool. We're going to set this pool to use .NET 2.0 (which also includes 3.0 and 3.5)

The most important reason for a new application pool is to set this pool/worker process to run in 32 bit mode. Select the new application pool and choose Advanced Settings. Change Enable 32-Bit Applications to true.

If you do not set the pool to run as 32 bit, you will get an error message that says:

"The page you are requesting cannot be served because of the Multipurpose Internet Mail Extensions (MIME) map policy that is configured on the Web server. The page you requested has a file name extension that is not recognized, and is not allowed."

A new behavior in IIS7 is a change between virtual directories and applications. In IIS6 and below, we would create a virtual directory, and then add an application to the properties of that virtual directory. With IIS7, we right click and instead of choosing Add Virtual Directory we choose Add Application. So let’s add a new application to the Default Web Site.

For simplicity, I'm re-creating the structure exactly as defined on my Windows 2003 server. Once the application is created, right click on it and choose Add Application. So right click on the default web site and choose add application. Call it Mapguide2009 and choose the newly created mapguide2009 application pool.

Next we need to right click on the Mapguide2009 application and create two new applications. One called mapviewerdwf, and mapviewerajax. Each of these apps must point to the same location – the mapviewernet folder. (by default its location is C:\Program Files (x86)\Autodesk\MapGuideEnterprise2009\WebServerExtensions\www\mapviewernet – but we need to use c:\inetpub\wwwroot\ MapGuideEnterprise2009\WebServerExtensions\www\mapviewernet) The other difference is that for each application, we must set the default document to be dwfviewer.aspx and ajaxviewer.aspx respectively. To set the default document select the new application in the tree and double click Default Document in the central pane. Enter the appropriate default document.

Next we need to setup a script mapping for the FCGI. Select the Mapguide2009 application and we are going to create yet another application. Call this application mapagent. This should act like adding an application to an existing folder in IIS6. Next, double click on Handler Mappings. In the top right, select Add Script Map. On the script mapping form, enter MapAgent.fcgi (or *.fcgi) for the request path. Browse to and select the isapi_MapAgent.dll from the www\mapagent folder. Under request restrictions, you can also set the verbs to GET,POST.

Click Ok and you will be prompted to enable the ISAPI extension. Click on yes.

At this point – the Mapguide 2009 web tier should be installed and running. Try it out by starting up a browser and hitting http://localhost/mapguide2009/mapagent/index.html. Next you can access maps using http://localhost/mapguide2009/mapviewerdwf or mapviewerajax.