Right now, I am creating an msi and a setup.exe using the Visual Studio. It works quite well... till recently.
I recently added a new dialog box with a Combo Box Control to the msi. Now when I install the app directly using the msi, everything is works just fine.
But when I run the Setup.exe, the ComboBox is not displayed correctly. It only displays one element at a time in the drop down list. All the elements are still there, and I can even select them using the Up/Down keys or the letters ('S' for SQL Server, for instance).
Has anyone seen this kind of a problem before? Moreover, when I use InstallShield to create the setup, the exe created by InstallShield again runs fine.
So I suppose I need to fix the one with Visual Studio. Any ideas how to do fix the visual studio bootstrapper?
Platform:
Using Visual Studio 2005 for the builds.
OS: Windows XP SP3.
The build machine has Windows Installer 4.5 installed, but its not a pre-req.
The msi itself runs fine with Windows Installer 3.
Also, the problem is not that the setup exits too fast, or that it doesnt install properly... It does. The only issue is that the Combo Box is not displayed properly and that might confuse some users.
What version of Visual Studio are you working with? Are you using VS2008 SP1?
There is a known issue with the bootstrapper from this version of Visual Studio being introduced in SP1. Maybe you are facing the same problem? You can check the details on this issue on Microsoft's connect site:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=369138
There is also a discussion going on here: http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/3731985c-d9cc-4403-ab7d-992a0971f686/
EDIT: Actually the thing that was fixed in SP1 could also solve your problem. The difference in SP1 is the way that the bootstrapper launches the actual MSI installer. Prior to SP1 the MSI installation (i.e. msiexec) was started as a child process of the bootstrapper (i.e. setup.exe). Now it is started as a non-child process and setup.exe returns as soon as the bootstrapping process is finished and the MSI is launched. You can see the difference also because before the buttons in the setup wizard were not using the Windows XP / Vista theme style.
I was unable to exactly find out WHY the VS bootstrapper was behaving the way it was, but grabbing another Setup.exe from another project (not built using VS) fixed the problem.
[I was under the impression that the Setup.exe has some kind of identifying information or a link to the MSI that it is supposed to kick off. Apparently not. Just throwing in the other setup.exe did the trick.]
Hope this helps someone.
In the .MSI itself what is the height setting of the combo box control? The height property controls the combined height of the selection area and the drop area. If it is set too low then you'd get the problem behavior you're describing (though that would not explain why sometimes it appears correct).
Related
Now I have some big problems with installing Visual Studio Community.
These problems came when I got back to Windows 7 from Win10 (because I had some problems).
When I launched the actual Visual Studio for the first time on Win7, it loaded good, but I didn't have any templates. So I decided to reinstall it.
Uninstall went good, but when I tried to install it again, it just stopped at Microsoft Visual Studio Hub Services or something like that. It just really stopped, when I let it go, the progress bar never moved. Then it also said that it couldn't find it or something similar.
And then the fun starts. I tried to do it several times, same. Then I downloaded the Visual Studio 2013 Community, and it stopped on Build x86. Same like the Hub Services at the 2015 version. I gave up at this moment. But after that, I went angry and removed the all Visual Studio folders in the Program Files.
But later on, I found the Visual Studio 2015 Express for Desktop, I downloaded it and that time it said right at the beginning: A Prerelease version of Visual Studio Community is currently installed. Please uninstall it prior to proceeding with your current installation.
I listened to it, went to Remove and Add Programs thing (don't know what name is it in english) and yeah, there was a version of that Visual Studio I removed. I tried to uninstall it, but it just said something again: The installation source for this product is not available. Make sure that the source exists and that you can access it.. And that's basically all.
So I would like to ask, how to fix this thing. It's because of that movement from Win10 to Win7? Or because of the VS folder deletement in Program Files? Any answers are very welcome!
EDIT: Main problem is that it stops at Microsoft Visual Studio Hub Services, I managed to uninstall the 2015 Community version, but then it stops and just didn't move, the only way was to remove the process to shut down the installing window and cancel the installing.
EDIT 2: Well, kinda shy of my grammar back then, fixed some bigger mistakes.
When Visual studio is installed, several other programs get installed. So when you try to uninstall visual studio, you should uninstall all other bunch of programs which were installed along with actual visual studio(which is a bit burden). It take so much time for me to uninstall all the programs from my computer. So while re installing please make sure you uninstall all the other installed apps also.
[EDIT: you may want to scroll to the bottom for the nuclear option which I wish I'd discovered earlier!]
I've downgraded two computers from Windows 10 to 7, both with VS2015 on them. One worked and the other had its VS2015 break horribly. I also deleted the VS2015 directory and registry data that mentioned VS2015 and all sorts, and I had even more problems than you describe :) I think the difference is that I installed some new things (node.js and TypeScript) under Windows 10, and they inserted things into VS2015 which were no longer properly installed after the downgrade.
Here are my discoveries in a hopefully useful order:
When it hangs, what it's actually doing is trying to display this prompt asking you to supply the path to an installer it couldn't find.
You usually get to see these prompts if you 'Run as Administrator' the (main) installer (rather than letting it obtain Administrator privileges itself). Process Explorer helps shed light on this: if the main installer's window is associated with the child process, then the dialogues are visible. If the root process, they're not.
The prompt relates to old versions of packages that the installer wants to uninstall prior to installing a new one, and for some reason the installer doesn't know how to re-download those packages. It is usually looking under C:\ProgramData\Package Cache for them.
If you aren't seeing the dialogue, you can view logs in C:\Users\<you>\AppData\Local\Temp. Use the 'Details' view and sort this folder by date modified, to help you find the right one. Each sub-installer tends to make a new file so you may have to poke around a bit. Changing dates or file sizes also tell you that it's doing something.
Messages like this tend to be associated with the attempt to show a dialogue:
MSI (s) (24:D8) [13:00:25:033]: SOURCEMGMT: Trying source C:\ProgramData\Package Cache\{388D7468-1CCA-40C8-9F08-4C20E972E922}v14.0.25123\packages\BuildTools_MSBuildResMsi_amd64\.
MSI (s) (24:D8) [13:00:25:033]: Note: 1: 2203 2: C:\ProgramData\Package Cache\{388D7468-1CCA-40C8-9F08-4C20E972E922}v14.0.25123\packages\BuildTools_MSBuildResMsi_amd64\BuildTools_MSBuildResMsi.msi 3: -2147287037
MSI (s) (24:D8) [13:00:25:033]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
So, what to do about these missing packages?
If you have another computer with a working Visual Studio 2015 installation, you can copy the entirety of Package Cache from there to your bad computer (no need to merge folders that already exist) and that will hopefully catch many of them.
For the rest, I tried a few third-party uninstallers, and Revo Uninstaller helped. Go into its settings and enable 'Show System Components'. Then, whenever you identify a problematic package, you'll usually be able to find it in Revo Uninstaller. If you uninstall it, you'll see the usual prompt (cancel it), and after it fails, Revo's 'Moderate' registry cleanup option does the trick ('Safe' didn't). If you use the Pro version then you can multi-select and use the 'Quick Uninstall' batch option, which isn't quite automated - yes, I'm afraid it will be tedious - but with some patience, you can get through everything.
Identifying the problematic packages is still a manual process, but the good news is that you can cancel many of the prompts during a run of the installer without it aborting, so you can collect a lot of package names as you go. You can also look for patterns in version numbers; for me, a lot of them were 14.0.15123` or something like that.
For me, just one package didn't show up in Revo Uninstaller, and I searched the registry myself and deleted some occurrences. I'm not sure if that or the subsequent install of the new package was what did it, but even that one went away.
So, after all that, I'm pleased to report that Visual Studio 2015 has got through the 'Repair' operation with no further errors. I still need to reboot before I can see if it runs without a hitch...
[EDIT: Nuclear option follows]
It didn't. Many of the standard windows (code editor and error list to name a couple) failed to load with the error "An item with the same key has already been added". On the plus side, at least Visual Studio didn't suddenly exit moments after opening. So that's an improvement and 2-3 days well spent :)
After that:
I found this answer and tried the TotalUninstaller linked therein.
Then I deleted more of the installation where that uninstaller reported it couldn't delete a non-empty directory.
Then I was going to reinstall from scratch, but would you believe it - it gave me Modify/Repair/Uninstall options! So I ran the Uninstall. (Maybe Repair would have worked, who knows?)
Then I reinstalled from scratch.
There was just one more failed uninstall of an old thing (Microsoft Web Deploy), but it didn't even report a warning at the end because of it, and now my Visual Studio finally seems to be intact - fingers crossed! (I may never test that web deploy thing anyway - I mainly use it with Unity. Of course I had to install the Unity tools again.)
So yeah. I have no idea if this works by itself or if you also have to do all the other stuff. If you try it and find out, let us know.
Since you are still seeing Visual Studio in Remove and Add Programs, your environment may not be entirely clean and you will have to first completely remove Visual Studio from the system. This should be independent of whether you're using Windows 7 or 10.
You may need to do further research, but here are some initial pointers:
https://msdn.microsoft.com/en-US/library/Aa983433(v=VS.90).aspx
https://support.microsoft.com/en-us/mats/program_install_and_uninstall
Beyond trying those things and then re-attempting the install, please look for any logs generated from the failures. For example, in your %temp% folder.
In my case , I just restart the PC and after it boots up the VISUAL STUDIO 2015 will automatic come back and keep running. I did it with 2 PCs of users and with version Professional. Hope this helps.
Note : Please make sure to close all VS running on your PC before running install 2015 (in my case is VS Pro 2013) and make sure Windows updates have finished running (if they have).
Uninstall any version of visual studio 2015 you already might have installed.
Then, delete this key: I had a similiar issue and found finally as cause entries under
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\vs\Servicing\14.0. .
Whenever I try to debug a Visual Studio 2010 web project, VS hangs, and ultimately crashes. This happens if I try to start the project using F5, or through Attach to Process, before the process list even appears.
Hitting F5 in, for example, a Windows Form project works fine, but attach to process fails here too.
Any ideas on what can be causing this? Obviously attaching to the devenv.exe process won't work as I can't get the Attach to Process dialog to appear...
Oh, running W7 (x64), VS2010 SP1 (had same problems without SP1)
In Solution Explorer there is a Show All Files icon (highlighted in the photo below):
Make sure it's turned off,
When It's turned on, Visual Studio tries to index all the files in the solution and if you have a giant Solution it could take forever!
I hope this has helped someone :)
Have you recently installed Mono and/or Mono Tools for VS2010?
I found that to be the problem it my case. Not sure why, but it somehow got in the way.
Matthew
In my case hangs when executable type was not correctly set, ex. Managed v4.0 and trying to attach to Native.
Just installed VS2010 express for Windows Phone last night. Install went smoothly. It creates a project, compiles, and deploys the app to the emulator.
Here's the problem: When I try to "Add Reference" through the Project menu, I do not get the Add Reference dialog box. Same thing if I right click References in the solution explorer and click Add Reference. That's not all. "File...Open" and "File...Open Project" also fail to throw up an open file dialog box. When attempting any of these actions, the IDE quickly loses and regains focus. Even pressing a keyboard shortcut (Ctrl+O) causes the IDE to quickly lose and regain focus, but no open file dialog box appears.
This is what I have tried, not particularly in this order:
1. Turned off UAC
2. Monitored file and registry access using Process Monitor during a File...Open operation. File activity showed mostly "SUCCESS" with a few "FAST IO DISALLOWED" and a few "INVALID DEVICE REQUEST" results. Registry activity showed mostly "SUCCESS" with some "NAME NOT FOUND" and a few "BUFFER OVERFLOW" results.
3. Created a new, clean Windows account to run the IDE from
4. Forced a test project to add a reference to "System.Xml.Linq" by editing the ".csproj" project file. Project failed to load in the IDE.
I don't have these problems at all on 2 other Windows 7 computers with VS2010 C# express beta 2 installed. One machine is 32bit and the other 64bit, both Home Premium edition.
My system: Windows 7 Home Premium, 64bit
Other Visual Studio products installed: VS2008 C# express, VS2008 C++ express
One other thing to note: Several months ago I installed the non-phone distribution of VS2010 C# express beta 2, and I had the same exact problems. Back then I chalked it up to being beta and went back to VS2008 C# express, where I do not have these issues.
Matt, if you're still reading this post, I have a solution:
Do you have the Tablet PC Input Service disabled? Enable and start it. This was suggested to me over on the MSDN forums, and it worked for me immediately. I have this service disabled, but I turned it on, fired up VS2010, and it just worked right off. I confirmed this solution by turning the service off again, starting VS2010, and noting that it breaks once again. Turned the service on once more, started VS2010, and it works perfectly. Amazing.
I do not think it's acceptable to require this particular service just for VS2010 to function correctly. Hopefully they fix this in the inevitable service pack. FYI, I had this service disabled because I turn off all services I don't require. So now I have two "wisptis.exe" tasks eating up ~8MB of RAM and starting every time I turn on the PC. Or I can shut the service off again and just resort to my previous workaround. haha
Here is a work around.
Just run wisptis.exe from command line and start the visual studio.
If you don't wanna run each and every time you restarts the computer,then just put wisptis.exe in a .bat file and move it to the startup folder,so that it will be automatically executed on each and every startup.
EDIT 1 :- Or else just press 'WIN'+'R' and type 'wisptis' and press 'Enter'.
I experienced the exact same problem. I'm running VS2010 Express on Windows 7 (x64). Re-enabling the "Tablet Input" service "fixed" the problem.
VS2010 has always worked fine, and then suddenly for no apparent reason "ctrl-O", "Add Reference", "Open Project", and other similar functions stop working.
No amount of repair/uninstall/reinstall would fix the problem.
I always disable the "Tablet Input" service on Win 7, because I use a Wacom tablet, and dislike the visual notification of (tablet) mouse clicks this service causes. VS2010 has so far been working fine in this setup with Tablet input service disabled, but then suddenly the problem arose, and I had to re-enable the "Tablet Input" service to make it go away.
I have another computer with the exact same setup - Win 7 (x64), VS2010 Express, Wacom table, and disabled "Tablet Input" service - and here VS2010 is still working just fine. Both computers also have almost identical software installed and updates installed, so I still have no idea where the difference lies.
Has anyone had more luck in finding the root cause?
I also use Power Toys, but I have not been able to correlate this installation with the problematic behavior of VS2010.
I'm having close to the same issue with the exception that my New | Project dialog works, but Add Reference and Ctrl + O just cause the interface to lose focus and regain focus without every launching the dialog. I have tried running devenv /ResetAddin and devenv /ResetSkipPkgs, but neither helped. I have UAC turned off as well. I don't experience the issue with VS2008.
Here's my setup:
Windows 7 Ultimate x64
Visual Studio 2010 Ultimate RTM
Visual Studio 2008 Team System Developer Edition with Team Explorer 2008 and VS2008 SP1
The only addins I run:
GhostDoc
.NET Reflector
Other Related Products I run:
Microsoft Expression Studio 3
SQL Server 2008 Developer Edition with SP1
tonight I uninstalled the VS2010 Express beta 2+phone tools and installed the now final RTM VS2010 Express C#. It STILL had the problem! For kicks, I tried importing a VS2008 project because it has some extra references in the project, and I was curious how they would be handled. The project imported successfully, but compiled with errors that it couldn't find a reference for a SyndicationFeed object, even though the reference for it was successfully added to the References list upon import. I remove the reference (System.ServiceModel.Web), hold my breath, and try to Add Reference one more time. Amazingly, the Add Reference dialog pops up, I add the reference back, recompile and bingo. File...Open and File...Open Project now throw up the proper file open dialogs as well.
To be sure this isn't a fluke only related to importing an old project, I shut down VS2010, start it back up, create a brand new project and try Add Reference. It works still. The File/Project dialogs also show up. I have no idea how, but importing a VS2008 project apparently made VS2010 correct itself on my machine.
Thank you for replying to my post. After hours of Googling over the past few days, your post is the first I've seen of anyone else having this issue besides me.
I found a workaround, but it's annoying having to do this:
1. Create a new project
2. Close VS2010, don't bother saving the new project
3. Start VS2010 again, and everything works as it should. I can access the Add Reference dialog, and I can do a File...Open and Open Project from the menu and toolbar.
If I close VS2010 and start it again, it is broken once more. Performing my workaround fixes it again for that session.
Still looking for a permanent solution.
I finally figured out a work-around. If I temporarily disable the Power Tools, the original Add References dialog opens fine. After adding my references, I can enable the Power Tools again.
Seeing an issue when debugging in Visual Studio. All of the values under watch, and in the hover over window show up incorrectly. the only values that show properly, are values that are local to the method I am currently stepping through.
For example the watch value for 'this' when debugging shows the following under value
0x00000000ffac0388 { btnBack=0x00000000ffaccf20 btnReply=0x00000000ffacd200 btnForward=0x00000000ffacd420...}
some other variables show this, even though the variable is there.
error: 'this.foo' does not exist
The machine recently had windows 7 64 installed, since then this problem has occured.
Visual studio has been reinstalled on this machine, and we verified that the settings in visual studio were exactly the same as a different PC that is the same machine and config.
We finally figured out what the issue was. The devenv.exe was being set to run in xp compatibility mode (sp3). Doing a rebuild of the project after removing the compatibility mode fixed the issue.
Can you provide a bit more information to help us track down this problem. In particular
What operating system was installed before upgrading to Windows 7 64 bit?
Did you install Visual Studio before or after the upgrade?
Is there any other version of Visual Studio installed on the machine?
If you set your application to be x86 specific does the problem still repro?
What language is your code written in (assuming C#)?
When facing weird debugging issues, I find that deleting the solutions User Options file (.suo) usually fixes the problem. You will loose your bookmarks, breakpoints, any special exception handling, and so on.
If that fails then clear all your Visual Studio "temporary" files. Check out the "Clear Recent" script at http://missico.spaces.live.com/blog/cns!7178D2C79BA0A7E3!370.entry. Modify it for your own needs. For instance, I dislike Flash, so you may want to remove the call to ClearStupidFlash and the other non-Visual Studio calls. Clear your solution then "rebuild all".
If the problem still exists, then something else is going on.
Yes, I know... I could set up a virtual machine running XP. Unfortunately our build environment is such that we need to be running VC2003, 2005 and 2008 concurrently and it would be much more convenient if I could run 2003 natively on Windows 7 for the few projects we have that require it.
I realize some things may not be available in the IDE, but I was able to run 2003 under windows Vista and if I could get the same base level of functionality under Windows 7 I would be extremely happy.
Right now I get an error opening the *.pdb file when I compile after switching vc2003 to run as Administrator under compatibility mode for XP SP 2.
Thanks!
Give XP Mode a try if you can't get it to run natively.
http://www.microsoft.com/windows/virtual-pc/download.aspx
I wrote a blog entry about this a while back that you can check out - http://technikhil.wordpress.com/2010/01/12/visual-studio-2003-and-windows-7-can-get-along-really/
The only thing I am stuck on right now is the global search functionality of VS 2003 - it hangs the application. My workaround is to use windows 7 search :-). Other than that - so far so good...
Update: I got the search to work as well by disabling the Aero functionality - I have updated my blog post with the details...
(Much of this repeats what's already been written above.)
I need to run VS2003 as adminstrator under Win7 64-bit, to support legacy projects (e.g. those that run on the original Xbox). The old XDK requires VS2003, so upgrading is not an option. I could run WinXP but I prefer Win7.
VS2003 is not officially supported under Win7 and trying to do so creates a couple of fairly annoying problems:
Find-in-files causes VS2003 to hang.
Linking fails due to a PDB file handle leak.
The Find-in-files hang is solved by using "Disable visual themes". Navigate to the VS2003 shortcut (Start-->Microsoft Visual Studio .NET 2003), right-click to get context menu, select Compatibility tab, Settings pane, and check "Disable visual themes".
The linker failure (LNK1201) happens when you run the program through the debugger, stop it, modify a file and build. The error is that a Visual Studio hold a handle to the PDB file, while the linker tries to write to that file. You can stop and restart VS2003 to bypass the issue. Works but is annoying.
You can also use the Microsoft SysInternals "handle.exe" utility to find, then close handles held by a process on a particular file. Write a script to call handle.exe and set up the VS2003 project to run that script as a Pre-Build Event. (See this thread.) But handle.exe requires running as admin.
You could hypothetically change handle.exe to run as admin using the usual steps (e.g. as a compatibility setting) but then handle.exe (apparently) runs in a nested shell, and then the stdout text does not get to the calling script.
You can make VS2003 run as admin, in which case the Pre-Build script also runs as admin, hence does handle.exe, and that works.
The remaining trick is to get VS2003 SLN files to open properly. If you simply make VS2003 run as admin automatically then the VS version selector fails to run VS2003. I don't know why, but it is the case.
You could associate SLN files to open using VS2003 devenv.exe instead of VSLauncher.exe. That works but then all new SLN files (2005, 2008, 2010, 2012, ...) fail to open.
So the final step then is to make VSLauncher.exe run as admin. This fails as of KB2492386 as this thread indicates. Uninstalling that update was the final step in this saga, to get everything to work.
PATCH NOW AVAILABLE
After some reverse-engineering, I found the incorrectly refcounted COM object responsible for the leak (it was off by 1) and developed a stable patch and corresponding article describing the fix. This addresses problems encountered while using Windows 7 thru Windows 10. Details and download available at:
http://bytepointer.com/articles/vs7.1_2003_on_win7_pdb_handle_leak_bug_unofficial_fix.htm
If you want to perform the patch manually, those details are also included.
NOTE: The SysInternals Handle tool workaround did not work for files on a network-share. The .PDB was not completely unlocked although the Handle tool claimed it was closed. My fix eliminates the problem once and for all and avoids any side effects.
Run this install. You need to run it from the setup directory, the setup.exe on the root of the cd will not work.
D:\setup\SetUp.exe /NO_BSLN_CHECK
Solution i found on the web which helped: For your visual studio, use application compatibility = windows vista SP2, and NOT WinXP SP3
I have a really dirty and pathetic workaround for the pdb problem.
Download and run Sysinternals-ProceXP, press CTRL-F enter the name of pdb(smt like ($ProjectName).pdb) that can't be created while linking. Double click when it is found.(if it can't be found run procexp with administrator priviliges)
Then you will see that the .pdb file is highlighted in the lower pane of the main screen. Right click it and select Close Handle. When you retry building your solution it wont raise an error.
I dont know if this solution can be scripted but it is at least better than restarting visual studio.
I've been using Visual studio 2003 on win7 since the very first RC edition was released :S
why do people have issues?
I have attempted to install VS2003 on Windows 7 64-bit using the Virtual Windows XP feature. I'm reasonably certain that this will be successful. The issue I ran into is that the installer wants IIS installed, and the XP installation provided by the Virtual XP doesn't have that enabled by default.
If you go to Add/Remove components, and try to add it, it will ask for the disc, which I didn't have on hand. Once I get my hands on the disc, I'm pretty sure that it will run fine.
If you haven't tried it for other apps, the Virtual XP feature is really neat...
I am experiencing the same issue; devenv.exe is leaving pdb files open after running the project. I have made a batch file to work around it, it closes all .pdb files open by devenv.exe:
handle.exe .pdb | awk "/devenv.exe/ { split($4, fd, \":\"); system(\"handle.exe -c \" fd[1] \" -y -p \" $3)}"
You will need to have handle.exe by sysinternals and awk by gnu in your path to make it work.
Use at your own risk. Closing handles can cause application or system instability.
In windows 7, there is the compatabiliy mode in the executable properties.
open:C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE\
then right click on the devenv.exe and select properties. In the compatability tab, select the "Run in compatability mode" and select "Windows XP" in the dropdown.
Try that, I am not sure if it works, but it is worth a shot.
I am having no problems with Visual Studio 2003 on Windows 7 64-bit.
Navigate to VS2003 devenv.exe (probably C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.exe)
Right-click and select Properties
In the Compatibility tab, check "Run this program in compatibility mode for:" and select "Windows XP (Service Pack 3)"
Check "Run this program as administrator"
I got Visual Studio .NET 2003 Working just fine on my HP EliteBook Workstation 8760W with an I7 processor and 12GB of RAM running Windows 7 Professional 64 bit by doing some advanced steps.
They go as follows:
Install FrontPage 2002 Server Extensions for IIS 7.0.
Install Visual Studio .Net 2003. Just skip when the installer command you to configure Frontpage 2002 Server Extensions.
Install .Net Framework 1.1 Service Pack 1 (download here).
Go to Control Panel > Administrative Tools > Internet Information Services (IIS) Manager. Highlight your machine, then double-click on ISAPI and CGI Restrictions. Change setting for ASP .NET v1.1.4322 to Allowed.
Then it will always show an alert with the following message
This program has compatibility issues...
just ignore that. Also, don't put it in compatibility mode in the properties of the IDE.
I did managed to install VS2003 on Windows 7 32 bit. However I had to do some IIS tricks in order to be able to run my ASP.NET project. When you install VS2003 Web Development component can't be selected. Basically you have to drop your VS2003 ASP.NET v1.1 into C:\inetpub\wwwroot\project_name and make it working on it's own as a standalone web portal first. Here is the steps I did.
Install IIS on Windows 7
Copy your VS2003 project to C:\inetpub\wwwroot\project_name. Right click on your project_name and Convert to application.
Following was my custom issue that didn't work until I enabled Windows Authentication even if I had no related settings in my web.config. Select your project_name > Authentication > enable both Anonymous and Windows Authentications.
Enable ASP.NET 1.1 in ISAPI and CGI Restrictions and make sure ASP.NET is added under ISAPI filters
Once I'm able to fire up my ASP.NET project in a browser go ahead and open project from your project location in my case is C:\inetpub\wwwroot\MHSScoreOrg\MHSScoreOrg.sln. I was able to run my project only when it was fully integrated on IIS.
I'm sorry, your build environment requires you to have VC 2003, 2005, AND 2008 running concurrently? I would really bet that your efforts would be better spent simply consolidating your build environment to just one environment.
Have you considered upgrading your solutions to vs2005, using MSBEE to target .net 1.1?