none
problem with 3.5 vsto addin after converting to 4.0

    Question

  • Background - I have an existing vsto excel addin built in vs2008 for .net 3.5sp1.  The goal is to migrate to vs2010 targeting .net 4.0, but the first step is to get to vs2010, still targeting 3.5. 

    On my dev machine already having vs2008, i installed vs2010.  Made a copy of my existing solution. Converted the solution to vs2010, leaving all projects targeting 3.5  Everything seemed to be cool.

    So I changed all projects, including the addin project, to target 4.0.  This required me to make several changes to the various interop assembly references in various projects. Also, I had did set the "embed interop types" everywhere it made sense to do that.  I may not have gotten everything correct, but in the end my addin would load and run under 4.0.  I was happy.

    Now, when I go back to the original copy of my solution and load it up in vs2008 and try to run my addin again, the addin will not load and I get the error shown below.

    Looking at that error, I can see that there are several references to the VSTO 10.0 runtime, and that the error event source is VSTO 4.0.  Looking at the loaded assembly list, I see a mix of 4.0 and 3.5 stuff.  And the error itself seems to reflect some confusion as to which version of .net is trying to be used here. Specifically, note that there are both 9.0 and 10.0 versions of the assembly Microsoft.VisualStudio.Tools.Applications.Runtime. Should that be?

    Also, when I look in the assembly references in my original vs2008 solution now, some, not all, of the vsto related assemblies are coming from a different location than before. For example this one is different -  c:\Program Files\Reference Assemblies\Microsoft\VSTO40\v9.0\Microsoft.Office.Tools.Common.v9.0.dll

    What the F is going on here?  

    More importantly, what do I need to do to get things right again?

    Is it going to be a problem trying to run vs2008 and vs2010 side by side on the same machine, trying to make this migration?  Is there some way to manage that?

    Thanks for any clues or suggestions...


    Customization URI: file:///C:/dev/build/references/Axiom.UI.2007.ExcelAddin.vsto
    Exception: Exception from HRESULT: 0x8004063E


    ************** Exception Text **************
    System.Runtime.InteropServices.COMException (0x8004063E): Exception from HRESULT: 0x8004063E
       at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
       at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode)
       at Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.ValidateCurrentClr(String manifestLocator)
       at Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.CreateCustomizationDomainInternal(String solutionLocation, String manifestName, String documentName, Boolean showUIDuringDeployment, IntPtr hostServiceProvider, IntPtr& executor)


    ************** Loaded Assemblies **************
    mscorlib
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
        CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
    ----------------------------------------
    Microsoft.VisualStudio.Tools.Office.Runtime.v10.0
        Assembly Version: 10.0.0.0
        Win32 Version: 10.0.21022.1
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualStudio.Tools.Office.Runtime.v10.0/10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualStudio.Tools.Office.Runtime.v10.0.dll
    ----------------------------------------
    System
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
    ----------------------------------------
    System.Core
        Assembly Version: 3.5.0.0
        Win32 Version: 3.5.30729.4926 built by: NetFXw7
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Core/3.5.0.0__b77a5c561934e089/System.Core.dll
    ----------------------------------------
    System.AddIn
        Assembly Version: 3.5.0.0
        Win32 Version: 3.5.30729.4926 built by: NetFXw7
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.AddIn/3.5.0.0__b77a5c561934e089/System.AddIn.dll
    ----------------------------------------
    Microsoft.VisualStudio.Tools.Applications.Hosting.v10.0
        Assembly Version: 10.0.0.0
        Win32 Version: 10.0.21022.1
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualStudio.Tools.Applications.Hosting.v10.0/10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualStudio.Tools.Applications.Hosting.v10.0.dll
    ----------------------------------------
    Microsoft.VisualStudio.Tools.Applications.Runtime.v10.0
        Assembly Version: 10.0.0.0
        Win32 Version: 10.0.21022.1
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualStudio.Tools.Applications.Runtime.v10.0/10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualStudio.Tools.Applications.Runtime.v10.0.dll
    ----------------------------------------
    Microsoft.VisualStudio.Tools.Applications.ServerDocument.v10.0
        Assembly Version: 10.0.0.0
        Win32 Version: 10.0.21022.1
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualStudio.Tools.Applications.ServerDocument.v10.0/10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualStudio.Tools.Applications.ServerDocument.v10.0.dll
    ----------------------------------------
    Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0
        Assembly Version: 9.0.0.0
        Win32 Version: 9.0.30729.4130
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0/9.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0.dll
    ----------------------------------------
    System.Windows.Forms
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
    ----------------------------------------
    System.Drawing
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
    ----------------------------------------
    System.Deployment
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Deployment/2.0.0.0__b03f5f7f11d50a3a/System.Deployment.dll
    ----------------------------------------
    System.Configuration
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
    ----------------------------------------
    System.Xml
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
    ----------------------------------------
    System.Security
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Security/2.0.0.0__b03f5f7f11d50a3a/System.Security.dll
    ----------------------------------------
    System.Xml.Linq
        Assembly Version: 3.5.0.0
        Win32 Version: 3.5.30729.4926 built by: NetFXw7
        CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml.Linq/3.5.0.0__b77a5c561934e089/System.Xml.Linq.dll
    ----------------------------------------



    roger reynolds
    Saturday, May 22, 2010 5:28 PM

Answers

  • By VSTO Solution we mean VSTO AddIn

    1 To uninstall the 4.0 AddIn on your Dev machine open the solution in Visual Studio 2010 and from Project menu select Clean Project

    2. You need to Rename your the VSTO AddIn project and it's output assembly name.


    Navneet
    Monday, May 24, 2010 6:33 PM
    Moderator

All replies

  • Hi Roger,

    you have 2 addins on a machine with probably the same name which one targets 3.5 and the other targets 4.0. the assemblies with 9.0 and 10.0 are not .NET 4.0 assemblies. I would suggest not to have both these addins installed on your machine or uninstall one when you are trying to debug another. Please refer to the following posts for more information:

    http://blogs.msdn.com/vsto/archive/2010/04/23/why-should-i-upgrade-from-net-framework-3-5-to-net-framework-4.aspx

    http://blogs.msdn.com/vsto/archive/2010/04/15/upgrading-vsto-projects-to-use-with-visual-studio-2010-navneet-gupta.aspx

    Hamed

    Monday, May 24, 2010 2:09 AM
    Moderator
  • Thanks for the info, a couple of those links look very helpful. 

    You have exactly nailed my scenario, in terms of my needing build and test both 3.5 and 4.0 versions of the addin on the same machine.

    What do you mean exactly by "installed on the same machine" and "uninstall one" in terms of the versions of my addin?   What I do is set the registry key HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\MyAddinName\LoadBehavior to 3 (to load) or 1 (to not load) before starting excel.  Is that what you mean by uninstalling (setting this key to 1)  or is there some actual uninstallation processes that I am not aware of?

    It sounds like you suggesting that if I am to develop/maintain both 3.5 and 4.0 versions of my addin on the same dev machine, then I need to rename one of them.  That isn't a big deal, in fact it probably makes good sense to rename the 4.0 version anyway.  I would then of course have to select whichever one of them that I want to load for a given excel session before starting excel. Does that sound right?

    thanks

    roger

     


    roger reynolds
    Monday, May 24, 2010 3:53 AM
  • Hi Roger,

    You need to completly unregister one AddIn before installing the other, When you have both VSTO3.0 (VS 2008 creates VSTO3.0 solutions) and VSTO 4.0(VS 2010 creates VSTO4.0 solutions for both FX35 and FX40) installed on the machine the VSTO 4.0 is used to load both VSTO3.0 and VSTO4.0 addins. As you have installed the VSTO4.0 addin first there are some registry entries for improving load performance, these registry entries are causing the issue.

    If you uninstall the VSTO4.0 solution then all those registry entries are removed.

    You can not have two solutions by same name installed Side by Side, you can rename one of the solutions to have both installed side by side.

    That way you will have two entries under HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins for those addins and you can individually select which one to load.

    Thanks,

    Navneet


    Navneet
    Monday, May 24, 2010 3:55 PM
    Moderator
  • OK, but please help me understand excatly what I am to do here.  I don't know what you mean by "uninstall the VSTO4.0 solution".  Are you referring to uninstalling VSTO somehow?  Or something about my addin?  Something else?

    And, when you say "You can not have two solutions by same name installed Side by Side, you can rename one of the solutions to have both installed side by side", are you perhaps referring to my addin project as a "solution"?   I have a moderately large "solution" (visual studio .sln file) which has many projects, one of which is a VSTO addin. I'm a little confused by the lingo here.

    I think it will be fine to create a newly named version of my addin when I migrate it to 4.0 for real, so if that's what we're getting at here, then all should be good. But right now, I need to figure out how to get my current system to work again.  So - what do I really need to uninstall in order to make my old addin work again using vs2008 and VST0 3.0?  Once I get there, then I can re-do the 4.0 migration after renaming the addin.

    Thanks for you help.

    roger


    roger reynolds
    Monday, May 24, 2010 4:19 PM
  • By VSTO Solution we mean VSTO AddIn

    1 To uninstall the 4.0 AddIn on your Dev machine open the solution in Visual Studio 2010 and from Project menu select Clean Project

    2. You need to Rename your the VSTO AddIn project and it's output assembly name.


    Navneet
    Monday, May 24, 2010 6:33 PM
    Moderator
  • Success - mostly.

    I loaded the converted 4.0 solution in vs2010, did build/clean MyAddin  followed by build/Clean Solution.  Then closed vs without doing anything else.

    Then, I loaded my original solution in vs2008, cleaned both the project and solution again, then build, then try to debug my addin.  Same result.

    Then I renamed my addin assembly in the original vs2008 solution, and rebuilt and now it seems to work.

    I was kind of hoping that I would not have to rename my existing addin, and that I could instead give it a new name when I migrate to 4.0.   And I believe that that would be true, if I had started out that way. 

    Do you have any suggestions for how I might be able to get the old 3.5 version working under the old name? I notice that, even after project/solution cleaning, I see that in the registry there are still a few references to the old addin name around, in places like

    HKEY_CLASSES_ROOT\Interface\{some-guid}
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\Interface\{some-guid}
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface\{some-guid}

    And have values with various of my class names. In my 2008 version of the addin, I had ComVisible set as true as an assembly attribute.  I removed that when I converted to 4.0

    I am tempted to delete all of these keys from the registry and rebuild.  Do you think that would help or make things worse?

    Thanks very much for your help so far.

     


    roger reynolds
    Tuesday, May 25, 2010 1:42 AM
  • Why do you have COM Visible to your VSTO AddIn classes? Do you want to access the VSTO AddIn Classes from COM components?

    If the COM Visible (true) attribute is set for your custom classes then you need to find a way to unregister those classes and they are not registred when you clear the VSTO AddIn.

    I do not recommed modifing the registry by hand until you know what you are doing. There are lots of tools available including regasm and regsvr that have install/uninstall options.

     

    Thanks,

    Navneet


    Navneet
    Tuesday, May 25, 2010 2:00 AM
    Moderator
  • Yes, the addin implements an interface that is available for use by VBA running in excel.  

    Like I say, I am removing the ComVisible assembly attribute when migrating to 4.0, and instead tag just the few types that actually require it. I'm not totally sure where that road is going to lead me exactly.  Bit of a legacy thing...

    Hand editing the registry is definitely not something I want to do, but I really do need to find a way to get my old addin running by its old name. I tried regasm /u, but that didn't make any difference. 

    Any further guidance appreciated.

     


    roger reynolds
    Tuesday, May 25, 2010 3:25 PM
  • Usually I have found it hard to unregister classes/interfaces/type libraries if I do not know much about them, as this is your dev machine, I would suggest that easiest solution is to rebuild your machine. If your end users will also have your old and new AddIns installed side by side then it a different story where you need to find out how to get them working side by side. I wouldn't worry much about the dev machine.

     

    Thanks,

    Navneet


    Navneet
    Tuesday, May 25, 2010 9:19 PM
    Moderator
  • More information about COM Visible attribute and where and what is updated in Registry can be found here

    http://msdn.microsoft.com/en-us/library/h627s4zy(v=VS.80).aspx

    http://msdn.microsoft.com/en-us/library/zsfww439(v=VS.80).aspx

    http://msdn.microsoft.com/en-us/library/bctyca52(v=VS.80).aspx

    Thanks,

    Navneeet


    Navneet
    Tuesday, May 25, 2010 9:26 PM
    Moderator
  • It is really just the one dev machine that is affected.  The addin is deployed in the world, but I think we'll be able to avoid problems by giving the 4.0 addin a new name when we are ready to deploy it. Had I known, or been thinking straight, I would have renamed it before building it on the same machine, and probably avoided most of this bother.

    Its really pretty inconvenient to rebuild my dev machine right now, for a variety of reasons, so I'm going to try and salvage it first. In the end, I may have no choice, especially after I start screwing with the registry.

    Thanks

     


    roger reynolds
    Tuesday, May 25, 2010 9:32 PM