Incompatible with VS 2017

AdmiralSnyder commented 7 years ago

the extension doesn't work with VS 2017 Just modifying the manifest is not sufficient, because the ExecutionEngine fails.

I'll update the issue as soon as I know how to fix it.

justcla commented 7 years ago

Thanks! I'd be most grateful if you managed to upgrade it to VS2017. Let me know if I can help.

AmadeusW commented 7 years ago

@justcla VSMacros.csproj has COMReferences which make it impossible to build. I'm getting warnings like this:

Cannot find wrapper assembly for type library "EnvDTE90". Verify that (1) the COM component is registered correctly and (2) your target platform is the same as the bitness of the COM component. For example, if the COM component is 32-bit, your target platform must not be 64-bit. The referenced component 'EnvDTE90' could not be found.

The COM references are for EnvDTE100, EnvDTE80, EnvDTE90, Microsoft.VisualStudio.CommandBars (not on nuget) and stdole. I removed the COM references and added the EnvDTE nuget, and received lots of errors related to CommandBars

AdmiralSnyder commented 7 years ago

the com references only need to be reinstalled, then building is not a problem. then the version checking has to be adapted which works too then the vsix manifest has to be updated to v3 with dependencies / prerequisites. which is not difficult.at that point the extension installs fine and the problems start, because the execution engine will throw exceptions because it needs assemblies from vs2015. I'm working on that right now, but my csproj got destroyed (will file a bug if it is reproducable).

AdmiralSnyder commented 7 years ago

the first problem is the reference to visualstudio.shell.12.0.dll in VS2017 this is a .net 4.6 dll, so it cannot be loaded even if the dll is copied into the executionengine directory. so i changed all projects in the solution to .net 4.6, and the next error will happen. more debugging is required, but not today.

AdmiralSnyder commented 7 years ago

Yay, it's working now on my fork here: https://github.com/AdmiralSnyder/VS-Macros however, one has to copy the following assemblies from the IDE PublicAssemblies folder into the ExecutionEngine folder. We can use the AssemblyResolve hook to solve this, since we have a PID of a devenv process and can find the correct directory, however I don't know if this is also possible to solve with a modification of the references. This is where i could use help to decide.

Also, due to remapping to .net 4.6, we should have a distinct project for VS2017, right?

justcla commented 7 years ago

Thanks @AdmiralSnyder.

Which DLLs need to be copied?

AdmiralSnyder commented 7 years ago

I forgot to paste... Microsoft.VisualStudio.Shell.Framework.dll (not referenced in project)

Microsoft.VisualStudio.GraphModel.dll
Microsoft.VisualStudio.OLE.Interop.dll
Microsoft.VisualStudio.Shell.15.0.dll
Microsoft.VisualStudio.Shell.Immutable.10.0.dll
Microsoft.VisualStudio.Shell.Immutable.11.0.dll
Microsoft.VisualStudio.Shell.Immutable.12.0.dll
Microsoft.VisualStudio.Shell.Interop.8.0.dll
Microsoft.VisualStudio.Shell.Interop.9.0.dll
Microsoft.VisualStudio.Shell.Interop.dll
Microsoft.VisualStudio.TextManager.Interop.8.0.dll
Microsoft.VisualStudio.TextManager.Interop.dll

AdmiralSnyder commented 7 years ago

The first one must be copied too. (Microsoft.VisualStudio.Shell.Framework.dll )

justcla commented 7 years ago

Most of these can be referenced via NuGet, can't they?

justcla commented 7 years ago

Some notes:

It's ok to reference the Shell.12.0 from .net46. This is a build-time dependency. It doesn't affect the output.
Therefore, we should have no problem generating a single VSIX that installs to VS2013, VS2015 and VS2017
Those Microsoft.VisualStudio DLLs listed above should not be required in the output. Again, these are build-time dependencies, aren't they?
In the VSMacros.csproj you'll see how we copied the ExecutionEngine into different directories with associated config files for handling the Shell.12.0 binary redirect. Copy that for VS2017. :-)

That's all I've got for now.

olegtk commented 7 years ago

Oh, I got it. VS 2017 assemblies are not in the GAC anymore so ExecutionEngine process can't load them. I'd try to use AssemblyResolve instead of copying. Another idea is if we could somehow specify VS folders in the probing path in ExecutionEngine.exe.config. That would require install time updating of .exe.config, we probably cannot do that.

olegtk commented 7 years ago

Never mind probing path, that won't work as any directories in the probing path must be subdirectories of ExecutionEngine.exe base dir.

AdmiralSnyder commented 7 years ago

@justcla I did not get the nuget referencing to work for the visx. and if i do compile the project with the references on my machine, a mapping in the .config file shouldn't be needed, right?

AdmiralSnyder commented 7 years ago

@olegtk this works fine: `private static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args) { // somehow we are asked for a .resources file... just return null. if (args.Name.StartsWith("VisualStudio.Macros.ExecutionEngine")) { return null; }

        // get full devenv path. DevenvPID is the PID we parsed from the command line in Main.
        var devenvFileName = Process.GetProcessById(DevenvPID).MainModule.FileName;

        return Assembly.LoadFrom(Path.Combine(
            Path.GetDirectoryName(devenvFileName), 
            "PublicAssemblies", 
            args.Name.Split(',')[0] + ".dll")); // better not just split...
        // args.Name is "Microsoft.VisualStudio.Shell.15.0, PublicKeyToken... and so on"        
    }`

olegtk commented 7 years ago

Good. Something like that should work. We might also need PrivateAssemblies folder. Take a look for a sample at https://github.com/dotnet/buildtools/blob/master/src/common/AssemblyResolver.cs

AdmiralSnyder commented 7 years ago

is it really neccessary to check for the version of the PublicAssembly dlls? i mean, it doesn't really matter if we get an exception because we reference the wrong version of the file or because we don't reference any, does it?

olegtk commented 7 years ago

no, I don't think we need to verify versions of assemblies in PublicAssemblies folder.

AdmiralSnyder commented 7 years ago

okay. so i'm gonna try to reverse the projects back to .net 4.5 and VisualStudio.Shell.12.0, and add a lookup into PrivateAssemblies.

@olegtk I don't have VS2015 and VS2013 installed anymore. can you test if it still works? that would spare me the download of the VMs (and I just don't know if there is a VM with 2013...)

justcla commented 7 years ago

Excellent idea. Better for backward support to use the oldest versions you can get away with.

I can test it on VS2015 and VS2017. Thanks.

AdmiralSnyder commented 7 years ago

there is a problem with building in .net45 and vs2017 when adden Microsoft.visualstudio.shell.12.0 reference:

(that's why i originally changed to .net 4.6)

this is the german error message: Der primäre Verweis "Microsoft.VisualStudio.Shell.12.0" konnte nicht aufgelöst werden, da er indirekt von Assembly "Microsoft.VisualStudio.Utilities, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" abhängig ist, die anhand des ".NETFramework,Version=v4.6"-Frameworks erstellt wurde. Dabei handelt es sich um eine höhere Version als das aktuelle Zielframework ".NETFramework,Version=v4.5". ExecutionEngine

i cannot find Microsoft.visualstudio.utilities to add the reference manually. any ideas?

AdmiralSnyder commented 7 years ago

i guess we cannot even use reflection to workaround the problem since we cannot doad a 4.6 assembly in a 4.5 appdomain, correct?

AdmiralSnyder commented 7 years ago

okay, i guess we don't have much of a choice other than to release a separate Version for VS2017, don't we?

justcla commented 7 years ago

Fair enough. That's not a big problem anyway. Let's keep it simple and just release a separate extension for VS2017. We might be able to keep all the code together with shared projects or static links, so that fixes can be easily applied to all versions.

AdmiralSnyder commented 7 years ago

will the separate extension be in a new repository?

ejadib commented 7 years ago

What's the new repo?

AdmiralSnyder commented 7 years ago

@justcla Will you create a new repo for the vs2017 compatible extension?

justcla commented 7 years ago

I wasn't planning to. Instead I'll create a new branch for VS2015. Then we can keep the master branch current with the latest version of VS.

qtormanen commented 7 years ago

What is the current plan for packaging up and releasing a build with VS2017 support? Short of that, could I get a gentle push as to what I need to do to use the current mainline myself--would I just get the entire contents, build it and install the result? I've been holding off on upgrading our team to VS2017 because we can't use some of the macros we have (I know, I should just learn how to write my own extensions, but just haven't had time!). Thanks for the great work, guys!

justcla commented 7 years ago

I am working on releasing it yesterday and today. Hopefully will have something released next week.

However, you can most certainly build your own version. It's as easy as pulling down the master branch and building it.

justcla commented 7 years ago

VS2017 version is built and signed. We are testing it now.

MagicAndre1981 commented 7 years ago

Install-Package Microsoft.VisualStudio.CommandBars -Version 8.0.0 installs a unofficial nuget package which includes the commandbar dll

AdmiralSnyder commented 7 years ago

Just tested it with the release of august 12. seems to work. Marking as solved.

justcla commented 7 years ago

You beat me to the announcement. But thanks for testing it.

Enjoy!

microsoft / VS-Macros

Incompatible with VS 2017 #42