Has anything changed in VS2013 in regard to the loading of DLLs within a VSIX that has a ItemTemplate with an IWizard extension.
I know this works with VS2012.
My sln has a WizardExtension Class Library, an ItemTemplate, in which the .vstemplates refers to the Class Library containing the Wizard, and a VSIX.
In the Exp Instance, when trying to add a New Item to the debugging project, VS just provides the error message that the itemtemplate is trying to load the component.
As I said, I know that this works fine in VS2012. The class library is correct, as I can sign and load in the GAC and it is fine. But I don't want to load in GAC but keep it exclusively as a VSIX. I tried a .pkgdef to provide bindings, but that goes not solve issue.
Related
Our company has legacy system that heavily relies on T4 and the employee who architected it is gone. It was running fine for us, however recently some developers upgraded to VS2015. The T4 transformations stopped working for them (with error similar as reported below). It looked at though there were references to Microsoft.VisualStudio.TextTemplating.12.0.dll. They changed the references to '14' and all worked for them. However, the same project shared by other developers on VS2013 no longer worked with error:
Compiling transformation: The type
'Microsoft.VisualStudio.TextTemplating.TextTransformation' is defined
in an assembly that is not referenced. You must add a reference to
assembly 'Microsoft.VisualStudio.TextTemplating.14.0,
Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Are you able to run T4 on same project that is opened in both VS2013 and VS2015? One side note, there was a dependent assembly that the old employee made that all the TextTransformations derived from (it also provides helpers that are used in the *.tt files). Unfortunately it used an interface only present in Microsoft.VisualStudio.TextTemplating.Interfaces.10.0.dll, so that old reference is being dragged aroundÎ. Not sure if that is contributing or not. But basically here is the bottom line:
When all devs on VS2013, everything worked and references were:
Microsoft.VisualStudio.TextTemplating.12.0.dll
Microsoft.VisualStudio.TextTemplating.Interfaces.10.0.dll
Microsoft.VisualStudio.TextTemplating.VSHost.12.0.dll
Then when some went to vs2015, the only way to get it to work was to change out the 12.0* dlls with 14.0, but then vs2013 developers ceased to work.
UPDATE
I might not have clarified our complete setup. We have 20-30 *.tt files in a separate project that is included in the solution with the project that will have Text Transformations applied to it.
We have a helper Extensibility.CodeGeneration.dll (this references Microsoft.VisualStudio.TextTemplating.N.dll files as well) that have several static helpers and also base classes that derive from Microsoft.VisualStudio.TextTemplating.TextTransformation.
The 'templates' project that contains all the *.tt files, every .tt file use static methods from our helper dll. It also references all the same Microsoft.VisualStudio. dlls.
In every *.tt file, we have something that looks like this, where AreaTemplate is a class defined in the *.tt file itself and either derives from Microsoft.VisualStudio.TextTemplating.TextTransformation or one of the exposed base classes in our helper dll.
var template = new AreaTemplate { Settings = settings, Area = area, Layouts = layouts };
Write( template.TransformText() );
It was asked in comments how I obtained/used a 'host'. In searching through code we have a few common scenarios (all done inside the helper dll). In each instance, host is of type ITextTemplatingEngineHost.
Case 1:
var dte = (EnvDTE.DTE)( (IServiceProvider)host ).GetService( typeof( EnvDTE.DTE ) );
Case 2:
var hostServiceProvider = (IServiceProvider)host;
Given #3 above, I think I have to reference the Microsoft.TextTemplating dlls (and not just the Interfaces dll) due to the use/exposing of TextTransformation class.
Also, if I change references to in both my 'Helper' and 'Templates' project to 12.0...in vs2015, I get error about 'you must add reference to 12.0'...I have references to that in both applicable (in my eyes) projects...not sure why VS tells me to add it. I tried adding an explicit reference in the *.tt file using
<## assembly Name="$(ProjectDir)..\..\Assemblies\Microsoft.VisualStudio.TextTemplating.12.0.dll" #>
But then I got the error
The type 'Microsoft.VisualStudio.TextTemplating.TextTransformation'
exists in both
'c:\BTR\Source\Assemblies\Microsoft.VisualStudio.TextTemplating.12.0.dll'
and
'c:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.TextTemplating.14.0\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.TextTemplating.14.0.dll'
It is almost like there is a hidden/implicit reference to the latest Texttemplating already built into VS??
Not sure if our setup was a more complicated way to achieve our original goal, but I don't think I'll be able to unwind it and change if we are doing it the incorrect way.
Given our setup let me know if you think I am stuck or not. I was trying to figure out 'conditions' in MSBuild to help support both Visual Studios but couldn't succeed.
Thanks in advance.
Try changing the reference from "Microsoft.VisualStudio.TextTemplating.12.0.dll" to "Microsoft.VisualStudio.TextTemplating.Interfaces.12.0.dll". Each new version of Visual Studio services will have a new implementation assembly that will implement the previous versions interfaces. To maintain backward compatibility, you should only reference the interface assemblies and not the implementation assemblies. You might have to change the templates if they reference anything not in the interface.
Updated
Wow, so you have a pretty complicated setup and I don't know if you will be able to use it in both versions without changing the code like you did.
I think the main problem is in your helper class, in #3 you said that the AreaTemplate class derives from TextTransformation. TextTransformation is in the implementation dll so it will exist in each version of visual studio. If you helper dll is complied to reference it from 2013 and then you use that dll in 2015 it will not work.
When a T4 template is transformed, the text in the file is parsed into a class, that class is loaded into an app domain(separate from the one visual studio is running in) and the class's TransformText method is called. Since your templates reference your helper class, the helper assembly will be loaded into the new app domain, which will in turn try to load TextTemplating 12 in there too, the app domain will not be able to resolve the 12 reference because you are using VS 2015.
In the other direction when you reference text templating 14 from 2015 and try to use it in VS 2013 you will have the same problem, the app domain will not be able to find TextTemplating 14 because you are in VS 2013 and the 14 dll does not exist.
In the last scenario when you are in VS 2015 and your add a link to TextTemplating 12 in your tt files it is failing because the app domain created to run the template has already loaded the TextTemplating 14 dll then you also tell it to load the TextTemplating 12 dll. This goes back to my posts in the comments when I talked about VS backward compatibility, TextTemplating 12 and 14 have the same TextTransformation class in the same namespace and the runtime can't load them both so you get that error.
Few things you can try:
1) Put the TextTemplating 12 dll in the GAC on the VS 2015 machines. In theory, this will let the T4 AppDomain load both copies of TextTemplating and then VS 2015 would be able to use the 14 version while your tt files and helper dll use the 12 version. Leave the VS 2013 machines the same.
2) Do the same as 1 but in reverse, setup the projects to target 2015 and reference the 14 dll then on the vs 2013 machines GAC the 14 dll, not sure if this will work since the 14 dll might have other dependencies on newer vs assemblies.
3) On the vs 2015 machines figure out a way to do binding redirects for the T4 App Domain so that calls looking to TextTemplating 12 would be resolved to TextTemplating 14. Usually binding redirects are done in the app/web.config files but not sure how you would do them for T4, may have to peek at the code and see how the app domain is created and loaded.
I have faced the same problem and I think I have a solution, which works - use the VisualStudioVersion msbuild property to reference the right version of the assemblies. Something like this:
<Reference Include="Microsoft.VisualStudio.TextTemplating.$(VisualStudioVersion)">
<HintPath>..\Dependencies\Microsoft.VisualStudio.TextTemplating.$(VisualStudioVersion).dll</HintPath>
</Reference>
<Reference Include="Microsoft.VisualStudio.TextTemplating.Interfaces.10.0">
<HintPath>..\Dependencies\Microsoft.VisualStudio.TextTemplating.Interfaces.10.0.dll</HintPath>
</Reference>
Make sure the Dependencies folder has both Microsoft.VisualStudio.TextTemplating.12.0.dll and Microsoft.VisualStudio.TextTemplating.14.0.dll.
Seems to work.
We have a very similar scenario to yours, just a bit more complex because our T4 templates depend on a couple of DSL-Tools packages.
I’ve made some tests and in fact the solution for this problem is to remove any reference to Microsoft.VisualStudio.TextTemplating.12.0 and keep the references to the Interfaces assemblies. Exactly as pointed by Frank. This would make the projects and the templates compatible with both Visual Studio 2013 and 2015.
Unfortunately this doesn’t help in our scenario because DSL-tools projects require references to Microsoft.VisualStudio.TextTemplating.12.0 or Microsoft.VisualStudio.TextTemplating.14.0 because the DirectiveProcessor.tt template generates a class that derives from RequiresProvidesDirectiveProcessor, an abstract class that resides in one of those assemblies (depending on the version of Visual Studio you would want to compile the DSL-tools project with).
I suppose that is one of the reasons why DSL-tools projects are upgraded when you open them with higher Visual Studio versions… But that is a pain because it forces large teams like ours to upgrade Visual Studio all at the same time.
I have a Project Template that I want to make available to people that I work with. How should project templtes (and item templates) be deployed? According to MSDN on this page (https://msdn.microsoft.com/en-us/library/xkh1wxd8.aspx) you should use a vsix package, but template wizards must be installed to the GAC and a vsix package cannot do that.
It seems that you don't need the GAC after all. See:
Using IWizard in an item template without installing assembly in GAC?
Using IWizard in an item template without installing assembly in GAC?
I am getting the following error in the VS2010 designer:
System.Reflection.Adds.UnresolvedAssemblyException
Type universe cannot resolve assembly: Microsoft.Expression.Interactions, Version=4.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
It is a Silverlight project and the missing assembly is referenced by the project. The project compiles and runs fine.
I looked with fuslogvw and I can't find that error message.
Do I need to copy the dll somewhere where the Designer can find it?
This assembly is part of Blend SDK. You can install it for free from here:
Microsoft Expression Blend Software Development Kit (SDK) for .NET 4.
If you're using zipped .dll's downloaded from the web under Vista or Win7, the OS blocking feature can cause this problem. I wrote up a blog post last week about how to unblock prior to unzipping a file. I know it solved a very similar problem I was having with Ninject.
I also faced this problem an finally resolved it in an unusual but successful way.
We are using Blend SDK's System.Windows.Interactivity and Microsoft.Expressions.Interactions.
Everything works fine, unless the designer crashes when using an inherited DataTrigger with the same Exception. This would not be the mess, but the exception also breaks IntelliSense in the whole XAML Document, which is not acceptable.
Since this is a reprocducible and reportet error, I decided to solve the problem using disassembling, since we need the extensions to the Interaction Framework.
See: http://connect.microsoft.com/VisualStudio/feedback/details/648819/visual-studio-2010-silverlight-designer-crash
Simply get a Versions of SharpDevelops ILSpy, and open the two assemblies within it. Select the assembly from the list and go to File -> Save. This will disassemble the whole projects. Integrate those in a blank solution and change the assembly names. Rebuild the reference from the Expression.Interactions library to your new disassembled version.
In the AssemblyInfo.cs you can do a trick.
In Microsoft.Expression.Interactions:
[assembly: XmlnsPrefix("http://yourdomain.com/interactions", "i")]
[assembly: XmlnsDefinition("http://yourdomain.com/interactions", "Microsoft.Expression.Interactivity.Core")]
[assembly: XmlnsDefinition("http://yourdomain.com/interactions", "Microsoft.Expression.Interactivity.Input")]
[assembly: XmlnsDefinition("http://yourdomain.com/interactions", "Microsoft.Expression.Interactivity.Layout")]
[assembly: XmlnsDefinition("http://yourdomain.com/interactions", "Microsoft.Expression.Interactivity.Media")]
in System.Windows.Interactivity:
[assembly: XmlnsPrefix("http://yourdomain.com/interactions", "i")]
[assembly: XmlnsDefinition("http://yourdomain.com/interactions", "System.Windows.Interactivity")]
Now put a reference to the new projects in your assembly, or build the assemblies and copy a version of them to your libraries folder and reference the built versions directly.
In XAML add the new namespace to your rootelement like page/window:
<RootElement xmlns:i="http://yourdomain.com/interactions">
<!-- your xaml code -->
<i:Interaction.Triggers> ... </i:Interaction.Triggers>
</RootElement>
It works like a charm. You can use both interaction and expressions functionality combined into one xmlns and of course, the designer exception is gone and IntelliSense will no longer break.
I have created an extension for VS 2010 that deploys a project template. The project template uses a custom wizard (in a specific assembly) that is called when I create a new project based on this template.
I want to package the assembly containing the wizard within the VSIX, so that it gets deployed somewhere the template can find it (I know GAC is not an option with VSIX).
Basically if I deploy the assembly to the GAC, install the VSIX and then create the project the wizard is invoked successfully.
If I do the same without deploying the assembly first, the project templates does not find the assembly when I create the project.
My question is: how to deploy a project template and the assembly it needs using a VSIX package?
Thank you for your help
EDIT: I changed the VSIX Sub Path of the wizard assembly reference to "ProjectTemplates" in both the installer project and updated the vsixmanifest content assembly reference accordingly. It seems to work now.
You don't need to get your assembly containing the IWizard implementation in the GAC. You can simply declare it in your extension.vsixmanifest file as an Assembly element in the Content section.
Unfortunately, this doesn't appear to be documented well anywhere.
The only tricky part is making sure that the AssemblyName attribute has the correct value.
I had no luck with the Assembly element technique to work, so in case anyone else runs into the same problem, here's another solution.
Visual Studio looks for wizard DLLs using the BindingPaths registry key. If you add the folder containing your DLL in a subkey of BindingPaths, then Visual Studio will find your DLL.
To do this from a VSIX, create a .pkgdef file in your VSIX project. Set its Include in VSIX property to True, and paste the following text into it:
[$RootKey$\BindingPaths\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}]
"$PackageFolder$"=""
(where the Xs represent the package GUID, though I suspect any GUID will do).
This works for me:
[$RootKey$\BindingPaths\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}]
"$PackageFolder$"=""
But assembly element doesn't work.
I have installed the strong named assembly TestReflection into the GAC (I am using .NET 4.0 and VS 2010).
Different versions of the TestReflection DLL are in GAC of .NET 4.0 (C:\WINDOWS\Microsoft.NET\assembly\GAC_32\TestReflection\), however, the assembly does not appear in the "Project" -> "Add reference" box of VS 2010.
How can I refer to my assembly deployed in GAC at design time from another project?
This page says that:
You cannot add references from the Global Assembly Cache (GAC), as it is strictly part of the run-time environment.
Referring to this statement, I would like to know how to make your project's DLL shared assembly for other consumers if it's the requirement?
The dll's shown in the .Net tab of the "Add references" dialog are not actually the ones registered in the GAC. They are found by searching a few paths on your filesystem.
The paths being searched are located by Visual Studio by looking up the following registry entries:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NetFramework\{Version}\AssemblyFoldersEx\
There should be some keys added there already, so if you want your own dll to show up on the .Net tab, you can add it to one of the folders defined there. You could also add a new registry key pointing to a custom folder, which would only contain your own dll's.
The GAC is only meant for loading assemblies at runtime after your application has been deployed, so I don't think you should use it while developing. When you deploy your app, make sure to set "Copy local" to false on your reference so the dll won't be copied to the bin folder, and then install it into the GAC and it will be loaded from there instead.
Another simple option would be to manually edit the project file as XML in visual studio (You will have to unload the project first), and simply add node <Reference Include="<name of dll>" /> in MSBuild project file. After reloading the project, VS will pick up the reference without problem.
If you want to add Global Assembly Cache references to your VS2010 project, there is an extension you can use: Muse.VSExtensions.
It has some quirks but does a decent job. Check it out...
The answer is the Reference Paths in the property windows, you have to set it with the GAC path
Please see my post here: