VS2022 Extensibility: How to resolve "The type 'XXX' exists in both 'Assembly 1' and 'Assembly2' in T4 template execution
Asked Answered
B

4

16

I have an extension I'm updating from VS2019 to VS2022. It's a DSL using the Modeling SDK and has code generation via T4 templates.

I have it pretty much converted but, when running the T4s, I get

Compiling transformation: The type 'SourceControl' exists in both 'EnvDTE, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'Microsoft.VisualStudio.Interop, Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
Compiling transformation: The type 'Project' exists in both 'EnvDTE, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'Microsoft.VisualStudio.Interop, Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'      
Compiling transformation: The type 'Constants' exists in both 'EnvDTE, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'Microsoft.VisualStudio.Interop, Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'    
Compiling transformation: The type 'ProjectItem' exists in both 'EnvDTE, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'Microsoft.VisualStudio.Interop, Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'  
Compiling transformation: The type 'ProjectItems' exists in both 'EnvDTE, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'Microsoft.VisualStudio.Interop, Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' 
Compiling transformation: The type 'DTE' exists in both 'EnvDTE, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'Microsoft.VisualStudio.Interop, Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'          
Compiling transformation: The type 'Solution' exists in both 'EnvDTE, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'Microsoft.VisualStudio.Interop, Version=17.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'     

and can't figure out how to resolve this.

I'm not including those assemblies in my main .tt file, nor are they referenced in my Dsl or DslPackage projects, but I understand from some other errors I had to resolve that EnvDTE8.0 and Microsoft.VisualStudio.Interop are implicitly available as part of the ambient VS2022 environment. Since they're not part of my projects, I can't use the Visual Studio Alias mechanism to disambiguate.

I've read the other questions on SO regarding similar issues, but none of them are this problem and their solutions really don't apply.

Thanks for any help or direction anyone can give.

Beaut answered 15/11, 2021 at 13:17 Comment(0)
F
24

I ran into a similar issue today with my T4 templates. After looking at your post and noodling on it for a couple of minutes I tried the following

I found the file that was adding the EnvDTE assembly

<#@ assembly name="EnvDTE"#>

and changed it to

<#@ assembly name="Microsoft.VisualStudio.Interop"#>

and that resolved my issue.

Friction answered 15/11, 2021 at 16:2 Comment(2)
And that did it for me as well. You got me to looking deeper, and finding the 12 other spots where EnvDTE was included (and didn't need to be); getting that resolved and replaced with Microsoft.VisualStudio.Interop did the trick. Thanks, Craig!Beaut
If you used EnvDTE AND EnvDTE80 in VS2018 replace both, but leave the namespace-directive: <#@ assembly name="EnvDTE"#> <#@ assembly name="EnvDTE80" #> <#@ import namespace="EnvDTE" #> to <#@ assembly name="Microsoft.VisualStudio.Interop"#> <#@ import namespace="EnvDTE" #>Trinatte
W
3

Craig's solution didn't quite work for me. I found that this issue was raised in T4MVC's github here https://github.com/T4MVC/T4MVC/issues/136#issuecomment-1089244574

The suggested solution which worked for me was:

I fixed this by removing the assembly imports of EnvDTE, EnvDTE80, and Microsoft.VisualStudio.Shell.Interop. (The namespace imports are still necessary.)

This is clearly similar to the other suggestions but I think it's slightly different since those didn't seem to work for me, or I misunderstood them. To fix it all I did was delete the three suggested import lines.

Wingback answered 27/8, 2022 at 0:44 Comment(0)
F
2

try to delete the EnvDTE assembly.

<#@ assembly name="EnvDTE"#>

but the following code is still valid:

<# EnvDTE.DTE dte = (EnvDTE.DTE) ((IServiceProvider)this.Host).GetService(typeof(EnvDTE.DTE));#>

and I use VS2022.

Footworn answered 29/1, 2022 at 7:48 Comment(0)
H
0

In case you need the .tt file to work for both Visual Studio 2019 and 2022 ('cause some of your colleagues are stubborn), instead of the import, you could use an include like this:

<#@ include file="IncludeFileName.%VisualStudioVersion%.ttinclude" #>

Then in the IncludeFileName.16.0.ttinclude file you'll have:

<#@ assembly name="EnvDTE"#>

and the IncludeFileName.17.0.ttinclude file would be empty.

Hunt answered 20/11, 2023 at 12:41 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.