Yesterday I started doing some feature work on an existing piece of code being developed in Visual Studio 2008. The solution itself targeted the .NET 2.0 runtime and made use of ASP.NET AJAX 1.0 to spice up some of the interaction with pages.
Part of my feature work included adding a service reference pointing to a Windows Communication Foundation end-point secured with certificates (see this post for more about that).
In order to enable this I needed to change the project properties so that it now targeted .NET 3.0 to enable the context menu. As soon as I changed what “runtime” it targets I compiled the application and ran it up to see if anything had broken – sure enough the application fell over.
What happened was that my development machine did not have the ASP.NET AJAX 1.0 components installed and I hadn’t followed the fairly hairy procedure to enable this scenario.
Since I was only doing some back-end coding work I really didn’t want to have to spend much time getting my development environment into a state to do this kind of AJAX development so I set about figuring out what had happened and how to fix it.
It seems that when you change from .NET 2.0 to .NET 3.0 (or any other change for that matter) Visual Studio 2008 scans the reference list to see if there are any assemblies referenced from a higher level runtime – and if there are it seems to strip them out (or that is what I observed).
So whilst none of my code-behind referenced the ScriptManager, at runtime the ASP.NET compiler fell over because it couldn’t find it.
Given that it had been working previously, I suspect that the .NET 3.5 version of System.Web.Extensions actually falls back fairly gracefully to .NET 2.0 even if it isn’t supported.
Rather than continue in this .NET 2.0/3.0/3.5 hybrid environment I downloaded the ASP.NET AJAX 1.0 assemblies and put them into a file system folder and added a reference to them.
When I did this the references list for the project showed up a warning against both “System.Web.Extensions” and “System.Web.Extensions.Design”. Upon closer inspection it seems that Visual Studio 2008 was still loading the assembly information from the GAC (where there where only 3.5 versions of those two assemblies).
In order to fix this you need to look at the properties for both of the offending references and flick two values:
The Copy Local and Specific Version properties can be used to ensure that Visual Studio 2008 will use the references from the specific path supplied instead of “accidentally” loading them from the GAC.
Finally, the other thing that I needed to do was double check that the Web.config file knew to use that specific assembly version, and that it knew about the controls inside the extensions assembly:
Hopefully this helps someone who comes up against a similar problem as they continue to maintain .NET 2.0 code-bases with Visual Studio 2008.