Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
Description of this issue
Since Visual Studio 2008 beta 2 and the .NET Framework 3.5 beta 2 were released, we have heard of a few issues related to using ASP.NET controls in the VS IDE after installing beta 2. The issues we have seen so far include the following:
In the cases we've seen so far, the systems are running Windows Vista, and the file version of %windir%\Microsoft.NET\Framework\v2.0.50727\system.web.dll is less than the official beta 2 version of 2.0.50727.1378.
How to workaround this issue
If you run into an issue like this, you can uninstall .NET Framework 2.0 hotfixes and then re-install the .NET Framework 3.5 as a workaround.
There are some detailed instructions that explain how to do this at this location, including a list of the exact hotfixes that need to be uninstalled to resolve this issue.
You do not need to re-install the previous hotfixes after working around this issue. The .NET Framework 2.0 SP1 and 3.0 SP1 hotfix packages that are installed as prerequisites for the .NET Framework 3.5 beta 2 already include all of the fixes that were previously released as separate Windows Vista hotfixes for the .NET Framework 2.0/3.0.
Root cause of this issue
We have found a problem with how some Windows Vista-specific hotfixes for the .NET Framework 2.0 have been packaged in the past that can cause an incorrect version of files like system.web.dll to appear on the system. This means that if you have some specific .NET Framework 2.0 hotfixes installed on your Windows Vista system, you might encounter this type of file version problem and therefore also run into some issues when trying to use VS 2008 beta 2. Windows Vista is built from components, and these components have their own version information that is used to determine which files will be present on the OS. The versions of the files contained in each of the components does not have to match the component version, and that can lead to newer versions of components having older versions of files in some cases such as this.
<update date="8/6/2007"> Added more details about the issues seen within the VS IDE to improve discoverability of this issue and possible workarounds </update>
Will the final install be able to do more aggressive version checking (or whatever is necessary) to avoid people having to find this out?
The process of installing VS 2008, finding that you have a problem, establishing that it's probably *this* problem, uninstalling hotfixes and then reinstalling 3.5 would seem overly painful otherwise, and I could see a lot of people wasting a lot of time before they realise what's up.
Hi Kevin - The way that Windows Vista versioning rules work is something that the .NET Framework setup does not have any control over. However, this problem showed us a flaw in how component versions were being assigned for .NET Framework hotfixes for Windows Vista, and that packaging issue will be corrected to avoid this type of problem in future hotfix packages.
I've been through an epic getting VS2008B2 installed on Vista in the last couple of days.
Deceptively (given how fundamental the problem turned out to be), everything appeared to install OK, except SQL Express, which I didn't really care about at the time, though it might have been a harbinger of the trouble to come.
However, once in VS, I couldn't compile managed apps (the notorious Alink missing IALink3 message) and also couldn't open the Winforms editor (another well-known problem which gives a message about a service already present in a shell.interop DLL).
Starting from the alink.dll problem, I realised that the only alink.dll on the system (in the NET2.0 framework dir) was dated Nov 06 (Vista RTM), and clearly hadn't been updated to .NET 2.0 SP1.
It emerged that KB110806 (I can type that number from memory now, sigh) wasn't being installed at all - it starts the install OK, does TWO reboots (it turns out that the second is to rollback the first), and ends up with nothing installed - this was happening both on stand-alone install from the wcu directory of the install media and when running the full VS2008 installer. However, NOTHING stops the rest of the installation going ahead from here, though the app finishes up broken.
I THINK (though I have tried so many things that I'm not 100% sure, and am not a confident reader of CBS logs) that this was perhaps related to a serious WMI problem on my machine. (Only three months old but on its knees already - Vista certainly has accelerated the process of 'Windows Rot'). I don't know if the WMI-related errors in the CBS logs were primary or secondary symptoms, but I thought they should be fixed.
Anyway, I eventually got the stand-alone KB110806 to install and appear in the hotfix list, from which point it was pretty much plain sailing.
The inability to install KB110806 is perhaps related to something completely different which happened weeks ago. However, the fact that the install will carry on regardless of the fact that KB110806 rolled-back is a complete disaster. It certainly makes for time-consuming troubleshooting - a full VS2008 uninstall takes AGES.
I have tens of megabytes of CBS log if anyone wants to read it.
What are the symptoms of this bug? Will I see a distinct error message? Putting such a message in your blog post would help users who are blocked by this bug to locate the solution using search engines.
PingBack from http://testsubdomain.netmoviehost.com/possible-issue-using-aspnet-controls-in-vs-2008-beta-2/
Hi WillDean - I'm sorry for the hassles you encountered while trying to install beta 2. I believe that the behavior you're seeing when VS setup continues even after KB110806 fails is a bug in the setup return code processing that we have fixed post-beta 2. I will double-check and make sure though so we can at least try to avoid that type of frustration in the future.
Hi TedHoward - Thank you for the feedback. The symptoms were described in the link that I included in my post, I've added some information about the symptoms to my post as well to help improve discoverability via search engines in the future.
"...is a bug in the setup return code processing..."
Thanks for this. Of course, it's more than just a bug in the return code processing, because if SP1 is an essential prerequisite for VS (which it clearly is), then VS should refuse to install without it.
Do you recall how you fixed your issue with installing KB110806? I am encountering the exact same issue with an install and subsequent rollback and i'm exasperated to no end trying to install it!
Hi Olliejen - I'd suggest reporting this issue on the .NET Framework setup forum (http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1020&SiteID=1) because there are more folks who regularly read that forum who have expertise troubleshooting .NET Framework installation issues. When doing that, they will likely ask you to gather your log files for further analysis. You can use the tool described at http://blogs.msdn.com/astebner/archive/2007/11/21/6458047.aspx to gather the logs from .NET Framework 3.5 setup.