You're reset, Michael.

Edhy's helping me work through a few final changes to the way the IServiceProvider is access through the new VSPackage.  We're close, but you might still have problems with the VSIX that's currently posted.

Hi Ben,

Has there been any progress with the DLLs you emailed to Edhy?

I have just downloaded the posted VSIX and am getting the same error as Edhy when attempting to access the BindingField in the property sheet for a control



Best regards,

Andy

yeah I was wondering as well??

Hi Ben,
Hope you are around and well.

Please let us know how is this update coming up, we really need to get this issue with the BOM fixed to be able to continue working on our projects.

Thanks!!!

Edhy Rijo

OK, Edhy, the best I can tell from the Intellitrace that you sent me is that the exception is being thrown when the code tries to access the ProjectItem.Name property.  All of VS is COM objects, so that means the __ComObject has become unstable and is throwing that memory corruption exception.   I have not been able to reproduce it here.  The BOMapper writes the partial classes with no problem.  I did however, get a few InvalidOperationExceptions for accessing a disposed object when the timer fires to try to close the results window (we had to add that because VS 2008 had a bug that wouldn't allow you to close the window once it was opened modally).  

Hi Ben,

Thanks for the explanation, I will try it right now.

Ben, it is still crashing on me.  Let's clarify where the DLL path should be registered in my system Windows 10 Pro 64 bits.

I have old versions of the AddIns.dll and Extensibility.dll in C:\Windows\assembly

Now, your dlls included in the zip package will be registered in C:\Windows\Microsoft.NET\assembly\GAC_32.  Is this correct or should they replace the ones in C:\Windows\assembly ?

Edhy Rijo

Those are the ones built by the build server, so they are x86, and they will end up in C:\Windows\Microsoft.NET\assembly\GAC_32 after you install them with gacutil.  You might clear out the ones still in C:\Windows\Microsoft.NET\assembly\GAC_MSIL if you have any.  A just for grins, remove the ones from C:\Windows\assembly, since those are the .NET 2.0 ones that will no longer be used.

Hi Ben,

This is DLL hell coming back to me

I deleted the dll from here:  C:\Windows\Microsoft.NET\assembly\GAC_MSIL

The ones from C:\Windows\assembly I am not able to remove or delete, I will get "Access Denied" error.  My guess is that those were installed by the SF setup and windows installers then cannot be removed manually, not even using gacutil /uf or ur, so I think the BOM is actually using those DLLs in C:\Windows\assembly instead of the correct ones installed in C:\Windows\Microsoft.NET\assembly\GAC_32.

I don't know if anybody else is able to reproduce this issue.  Can you verify if you have in your test VM the dlls in C:\Windows\assembly ?

Edhy Rijo