valerio.net

Last week I installed the .NET Framework 3.5 SP1 Beta update to try and get some of the new WCF features.  I’m usually leery about installing beta software, but I really wanted to try out the new stuff, and I figured that I could help the Microsoft team find bugs if I ran into anything.  Bad choice.

Today I wanted to start a new WPF project, right from the template in Visual Studio 2008.  Upon opening Window.xaml, I was greeted with a nasty exception:

Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0×80131401)
   at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandle& ctor, Boolean& bNeedSecurityCheck)
   at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean fillCache)
   at System.RuntimeType.CreateInstanceImpl(Boolean publicOnly, Boolean skipVisibilityChecks, Boolean fillCache)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.Activator.CreateInstance(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityInfo, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(String assemblyName, String typeName)
   at System.AppDomain.CreateInstance(String assemblyName, String typeName)
   at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName)
   at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName)
   at MS.Internal.Package.VSIsolationProviderService.CreateIsolationProvider(String identity, AssemblyReferenceProvider assemblyReferences, IEnumerable`1 assemblyFolders)
   at MS.Internal.Providers.VSDesignerContext.GetIsolationProvider(IServiceProvider provider, IVsHierarchy hierarchy, AssemblyReferenceProvider assemblyReferences)
   at MS.Internal.Providers.VSDesignerContext.Initialize(IServiceProvider provider, IVsHierarchy hierarchy, UInt32 itemid, Object docDataObj)
   at MS.Internal.Providers.VSDesignerContext..ctor(IServiceProvider provider, IVsWindowFrame frame, Object docDataObj)
   at MS.Internal.Providers.VSDesignerContext.GetContext(IServiceProvider services, IVsWindowFrame frame, Boolean createIfNotExist)
   at MS.Internal.Designer.DesignerPane.InitializeDesigner()

Nice.  I googled around and found some posts with some suggestions for fixes.  None of them worked.  Here is what I tried.

1. In Visual Studio, Tools>Import and Export Settings>Reset All Settings
2. Uninstalled "Microsoft Silverlight Tools Alpha for Visual Studio 2008"
3. Uninstalled "Microsoft Silverlight"

I figured that the only way to get my system back to normal was to uninstall the .NET Framework 3.5 SP1 Beta.  After running the uninstaller, the next time I open Visual Studio, I’m greeted with a message box saying that it can’t parse the .csproj file because it can’t find the Microsoft.Build.Engine, Version=3.5.0.0 assembly.  Nice!  I just completely bricked my Visual Studio installation. I tried repairing it, but realized I’d left my Visual Studio 2008 installation CD back home, so it failed as well.

<rant> I really don’t get it.  The .NET Framework was supposed to solve a lot of these "DLL Hell" issues by giving version numbers to assemblies.  Sounds good.  But why do the installers for these things keep causing so many problems?  Shouldn’t the installer just copy the new DLLs into the Global Assembly Cache?  They have a different version number so they should be fine.  Why is the installation process more complicated than just copying the files into the GAC?  I really like the .NET Framework, especially the 3.0 bits and the 3.5 bits, but why should it take me literally a day to get my development environment set up, after installing 15 different packages and service packs, some of which conflict (as seen here).  And when something goes wrong, where do you even start to debug?  It’s extremely difficult to just start uninstalling things and reinstalling them, because you’re never sure if a bug is caused by installing something new, or by installing something new and then uninstalling it, leaving various things (registry keys, files, etc) behind?  This is a serious pain point, in my opinion.</rant>

Anybody out there run into this issue and/or solved it?

Update: I was able to get rid of the MSBuild error that uninstalling .NET 3.5 SP1 introduced by downloading and running Aaron Stebner’s .NET Framework Removal Tool, removing .NET 3.5, and then reinstalling .NET 3.5. Unfortunately, the same exception is still being thrown in the Visual Studio WPF designer and I’m conveniently back where I started.  At least I can build projects again.

Fixed: It turned out that the problem was caused by a 3rd party addin that I had installed.  StudioTools by Exact Magic was going to be the target of a future blog post until now.  I discovered the problem by attaching another instance of Visual Studio 2008 to an instance of Visual Studio as I opened the project.  Turned out that there were a bunch of exceptions being thrown by the StudioTools addin, so I decided to uninstall it.  Now my WPF projects open without a glitch.  I guess my earlier rant on .NET 3.5 SP1 Beta was not deserved, and instead I should be holding StudioTools in contempt.  Can’t really complain, though — it was free.  Guess that just goes to show that you need to be really careful which 3rd-party addins you really trust, since bad ones can lead to very bizarre errors.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.