Error on trying to open configuration

[codecadwallader]

Error on trying to open configuration

[codecadwallader]

That is certainly odd. Have you tried uninstalling and reinstalling CodeMaid?

[kgroener]

Yes I have, but sadly with no succes.
However, i do sometimes get a slightly different error message:

[codecadwallader]

That makes a little more sense, that is a Microsoft library that CodeMaid utilizes for its WPF windows such as the configuration dialog.

Two more things to try:

1. Check if the installed location for CodeMaid includes both the CodeMaid.dll and that System.Windows.Interactivity.dll. An example location:
   C:\Users\Steve\AppData\Local\Microsoft\VisualStudio\12.0\Extensions\jmwf1r1y.3s0

2. Try the latest beta release v0.7.4.2-beta to see if that works any better for you: https://github.com/codecadwallader/codemaid/releases/tag/v0.7.4.2-beta

[kgroener]

1. Both dll files are included at the installed location.
2. I have installed the beta version, but the error still happens

But after some more searching, I found out that disabling an other plugin I have installed fixed the problem. This plugin also happens to use a System.Windows.Interactivity.dll, but a different version (.NET 4.5).
Wich is probably causing the problem.

[codecadwallader]

Makes sense, good catch! What other plugin was it, and which version is it using?

[kgroener]

This is the other plugin:
https://visualstudiogallery.msdn.microsoft.com/3471d451-c1f1-4273-b305-acf81e4f8b32

As far as i could tell, it was using the .NET 4.5 version (file version: 3.0.30810.0) , and codemaid .NET 4.0 (file version: 2.0.20525.0)

[codecadwallader]

Thanks for the details, and that's good news - because I can fix that. CodeMaid updated to .NET Framework 4.5 with the v0.7.4 release but that DLL is still on .NET 4.0. The file version I have however is 3.0.40218.0. I'll proceed with making the update and generating a beta release that you can test out.

[codecadwallader]

Potential fix is in v0.7.4.3-beta, available in downloads here: https://github.com/codecadwallader/codemaid/releases/tag/v0.7.4.3-beta

[OmerRaviv]

@codecadwallader @kgroener I'm trying to fix a similar issue in my own VS extension, could you please let me know whether simply upgrading System.Windows.Interactivity to .NET 4.5 fixed the issue?

[OmerRaviv]

@codecadwallader I'm trying to fix a conflict between OzCode and CodeMaid which appears to be the exact same problem described here. OzCode currently depends on System.Windows.Interactivity 3.5, and so installing OzCode and the latest version of CodeMaid (0.7.6) from the gallery causes an exception and Visual Studio later crashes:

[XamlParseException: Could not load file or assembly 'System.Windows.Interactivity, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The parameter is incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))]
    System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings settings, Uri baseUri):242
    System.Windows.Markup.WpfXamlLoader.LoadBaml(XamlReader xamlReader, Boolean skipJournaledProperties, Object rootObject, XamlAccessLevel accessLevel, Uri baseUri):20
    System.Windows.Markup.XamlReader.LoadBaml(Stream stream, ParserContext parserContext, Object parent, Boolean closeStream):231
    System.Windows.Application.LoadComponent(Object component, Uri resourceLocator):336
    DebuggerShared.UI.StatusBarIndicator.InitializeComponent():28
    DebuggerShared.UI.StatusBarIconSpawner.InjectIndicator(DockPanel statusbar):0
    DebuggerShared.UI.StatusBarIconSpawner.Start():20
    DebuggerShared.Services.StartableServicesHandler.Execute(IStartable startableTask):0

[ArgumentException: The parameter is incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))]
    System.AppDomain.nApplyPolicy(AssemblyName an):-1
    System.AppDomain.ApplyPolicy(String assemblyName):34
    Microsoft.VisualStudio.Platform.VsAppDomainManager.MatchAssemblyName(AssemblyName reference, AssemblyName definition):3
    Microsoft.VisualStudio.Platform.VsAppDomainManager.InnerResolveHandler(String name):94
    Microsoft.VisualStudio.Platform.VsAppDomainManager.ResolveHandler(Object sender, ResolveEventArgs args):0
    System.AppDomain.OnAssemblyResolveEvent(RuntimeAssembly assembly, String assemblyFullName):43

I've tried updating our System.Windows.Interactivity to 4.5 like you have - that solved the problem.
But, I then went back and tested an older version of CodeMaid (0.7.4.2beta) that still used 4.0 against my new OzCode that uses 4.5, and got the same crash.

AFAICT this means that until we find a better solution, any two extension that reference different versions of System.Windows.Interactivity will cause conflicts. That means that even if OzCode and CodeMaid standardize on using 4.5, both extensions are still at risk of crashing when another 3rd party extension is installed that still references System.Windows.Interactivity 4.0 or 3.5.

Do you have any idea how we could reliably solve this?

[codecadwallader]

That sounds logical, and I agree with your assessment. Since Visual Studio loads extensions within its own process, I don't know of a way to isolate extensions so they each use their own third party dependencies.

A couple related links:

1. http://stackoverflow.com/questions/3158928/referencing-2-differents-versions-of-log4net-in-the-same-solution
2. https://msdn.microsoft.com/en-us/library/dd153782%28v=vs.110%29.aspx#avoid_loading_multiple_versions

The first indicates explicitly referencing up/down to a common denominator. We can't ask all 3rd party extensions to upgrade, nor if we stay on an older version (e.g. 3.5) we would still have the same problem with other extensions that have upgraded to 4.0 or 4.5

The second basically recommends against loading multiple version in the same AppDomain. It sounds like it works, but is prone to issues as you've encountered above.

Have you looked around Microsoft Connect or opened an issue there to see if the MS team has any thoughts?

[OmerRaviv]

I've logged an issue with Connect through the Visual Studio Industry Partners program. That should help get this issue prioritized, but unfortunately also means that the Connect ticket is not public. I'll update here as soon as I hear from them.

The worrying thing is that our automatic error reporting is telling me that this issue may be affecting quite a lot of users and may be related to quite a few other 3rd party extensions.

I've considered trying to somehow tweak the bytecode of the version of System.Windows.Interactivity.dll we deploy, to remove the strong naming and change its name to something like "OzCode.System.Windows.Interactivity", thus preventing any potential conflict. That solution however is fairly involved and I haven't been able to get it to work just yet.

[codecadwallader]

Sounds good, thanks for providing the update here.