cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Shark75
Level 4

Virtual Directory not created IIS6

I've been trying to convert one of our existing projects from IS12 to IS2010, but have got stuck with getting the IIS virtual directories to install properly on both IIS 7 and IIS 6. Strangely I've got everything working on IIS 7, but I can not find any way using the built in IIS components of InstallShield to install the virtual directory correctly on IIS 6. This all used to work fine when the project was in IS12.

I have a simple web application called "iManager" that sits under the default web site. So in IS12 I had the following in the IIS components in the IS project...
Web Sites
Default Web Site
iManager

iManager being a Virtual Directory with the Application Name set to iManager, which is very important as it needs to have this application name set to work.

In IS2010, this got converted and everything looks the same in the project. However it simply doesn't get installed on IIS 6 and in IIS 7 doesn't get installed with the application configured, so in both instances the conversion has resulted in the functionality no longer working.

So in IS2010, I tried everything from using Web Applications to Virtual Directories to sub applications, virtual directories with the same name, different names and so on, but could not find any combination where it would install as required on both IIS 7 and IIS 6.

I did find a combination that worked in IIS 7, but not IIS 6, so in the project I now have currently got a Web Application configured called "iManager" which correctly installs a Virtual Directory with iManager configured as the application name in IIS 7. However in IIS6 I get nothing installed at all, no virtual directory anything under the Default Web Site.

FYI, Windows 2008 Server R2 (64-bit) for IIS 7 and Windows 2003 Server R2 (64-bit) for IIS 6 are the OSs I'm using for testing. I'm not targeting 32-bit or 64-bit specifically in the IIS settings, but I am targeting ASP.NET 2.0 specifically.

The project is an InstallScript project (not MSI). I have tried a basic MSI project and get the same problems.

This looks like a bug in IS 2010.

Can anyone help?
Labels (1)
0 Kudos
(10) Replies
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

Can you attach a sample project that reproduces this behavior?
0 Kudos
Shark75
Level 4

Thanks for the reply. Yes, so I went about creating another test project to demonstrate the problem and of course it worked from a new blank project. :rolleyes:

So I went through all the IIS settings in the test project comparing them to my real one looking for differences and so forth. Finally I came across the setting that once set in the project stops the project working anymore....

If you set the ASP.NET Version on the Web Application from the blank it defaults to when you create it to, in our case, 2.0.50727, the Web Application will no longer install into IIS. Take the version away so it's blank again and it still won't install, so I guess once you've set it once, because it has been set at some point it, that means it will no longer work and you have to recreate the IIS component in the project.

Obviously we need to be able to set the version to 2.0.50727 because that's what our application works with.

Further more and interestingly, installing the same application on Windows 2003 R2 (32-bit) does not exhibit this problem at all, so it looks like the problem is restricted to the 64-bit version of Windows 2003 R2.

I've attached the project before and after the problem occurs when you change the ASP.NET version in the Web Application component of the project.
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

When using the ASP.NET Version setting, the IIS support will check at runtime to determine which version (32-bit/x86 or 64-bit/x64) of ASP.NET to register with. This is based off of the "ASP.NET Platform" setting in your project for websites or applications. If this setting is not specified, 32-bit is assumed to be the requested platform. However, on most 64-bit platforms, the default application pool setting is 64-bit. Since the ASP.NET platform and the existing application pool setting (especially on IIS 6) need to match, the runtime will throw an error if there is a mismatch between the requested ASP.NET platform and the existing application pool platform setting.

One way to resolve this issue is to use a property for the ASP.NET Platform version setting to control whether the setting should be x86 or x64. You can do this with a set property type custom action sequenced in the execute sequence before ISIISCosting. For the action settings:
Property Name: Name of a public property (ASP_NET_PLATFORM)
Property Value: x64
Install Exec Condition: VersionNT64

In the Direct Editor, add a new record to the ISIISProperty table with the following:
ISIISProperty: Unique name
ISIISItem_: Item key for your application in the ISIISItem table
FriendlyName: AspNetVerBitness
MetaDataValue: [ASP_NET_PLATFORM]

Pure InstallScript projects would use a similar approach, except using text-subs instead of properties.
0 Kudos
Shark75
Level 4

Thanks for the reply. I understand whay your saying, although it would be nice if InstallShield did this for you if it knows IIS 6 plays silly kippers with this.

I've tried implementing your suggested solution, but I can't get it to work in InstallScript. I'm not sure I understand fully what you are supposed to do in InstallScript projects.

Currently I've added the property using the Direct Editor as suggested with instead of [ASP_NET_VERSION] in the MetaDataValue. If you actually look at the ism file it adds this as a reference to a new string in the string table that has the text . Then in the Feature Installing function of the Web Server feature I call TextSubSetValue("", "x64", TRUE) (if it's 64-bit) or "x86" if it's 32-bit (determined using SYSINFO.bIsWow64).

This didn't do anything so I added TextSubGetValue to the same method and displayed it in a MessageBox and the value is blank, so it's obviously not substituting the text.

I've tried editing the ism file by hand so that (or <ASP_NET_VERSION> to be precise) is in the property value rather than a reference to a string table value, but still no joy.

There is no ISIISCosting function in the help or in the drop-downs to add either, so I couldn't look at sticking it there instead of in the Feature Installing function for the feature.

Could you elaborate more on how to implement this in InstallScript projects?

Thanks.
0 Kudos
Shark75
Level 4

I must admit I can't get your instructions to work on an MSI project either and nor can I build any sort of project that successfully installs a Web Application on Windows 2003 R2 64-Bit (IIS 6), even if I specifically set everything to 64-Bit.

I'm currently resorting to trying to create a virtual directory for this particular OS by hand in the script.

Are you able to create a Web Application on Windows 2003 R2 64-Bit using InstallShield's IIS functionality?
0 Kudos
Shark75
Level 4

It seems that the installation where the ASP version was set but not the platform has corrupted the IIS metabase. Using IIS Metabase Explorer I can see the virtual directory there, but configured right and it does not appear in IIS Management Console.

Using IIS Metabase Explorer I've cleaned up the badly installed virtual directory and now, when the platform is set to 64-Bit and the application pool is set to don't allow 32-bit apps to run, it installs ok.

It does highlight that InstallShield is corrupting the IIS metabase when the platform is not set and installing on Windows 2003 Server 64-bit.
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

One possible issue here is if the wrong ASP.NET platform is used, the IIS runtime as part of the InstallScript IIS support has already partially created the application. In the case where an incompatibile platform is specified, an error occurs. In the MSI case, the ISIISRollback action would then run and revert all changes made by the IIS runtime. However, InstallScript does not provide a rollback mechanism, and as such, any changes made to the system and not reverted. It is possible to work around this situation if needed (the OnIISVRootUninstalling event can be called manually).

I have attached a sample InstallScript project which conditionally sets a textsub based on the current platform and user input. This textsub is referenced by Application2 that was created in the IIS view and updated in the Direct Editor. This project does not attempt to remove a partially installed application that may result if the textsub is set to x86 on a 64-bit platform.
0 Kudos
Shark75
Level 4

Thanks. I see you are doing the text substitution very early on in OnBegin. How late in the installation sequence can text substitutions be made?

I must admit that setting the application to 64-bit and the application pool to don't allow 32-bit to run in the project settings works on all platforms that I've tested it on, 32 or 64-bit, 2003, 2008, 7 or Vista. The 32-bit OSs just ignore the 64-bit setting.
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

You can move this code to the OnIISComponentInstalled event, which calls into the IIS runtime to install any IIS related items for the component being installed. This is the latest point a textsub used by the IIS runtime can be set. Components are installed as a result of calling FeatureTransferData, which is called from OnMoveData in InstallScript projects, so the textsubs used by the IIS support could also be set up to this point if you don't want to add any IIS specific events to your script.
0 Kudos
sudhircn
Level 2

Hi,

We are currently using Installshield Devstudio 9.0. We are creating IIS Virtual directories using the feature "IIS Virtual Directories".

The setup project is Installshield MSI is not creating the virtual directories in IIS 7.0.

OS Details: Windows Vista, Windows 2008 Server all 32 bit machines

Couldn't troubleshoot what is the issue?
Is there any alternate way to achieve this?

Thanks,
Sudhir C.N.
0 Kudos