none
T4 - referencing assembly from the solution does not work in VS2010 (and used to in VS2008)

    Question

  • Hi,

      I am using T4 templates in which I reference the assemly from the same solution. I put the assembly into "References" and use it inside the T4 like this:

    <#@ assembly name="System.Core.dll" #>
    
    <#@ assembly name="System.Xml.dll"#>
    
    <#@ assembly name="BIG.Corpeum.ServiceReference.dll" #>    

      This used to work in Silverlight project  in VS2008.

      However in VS2010 it complains: "Metadata file 'BIG.Corpeum.ServiceReference' could not be found".

      The only way how I can make it working is to use full path to the assembly, which is not really a solution.

      How can I solve this? Any help appreciated ...

    Stefan

     

     

    Tuesday, April 13, 2010 4:26 PM

Answers

  • Stefan,

    In Visual Studio 2010, T4 no longer relies on the hosting Visual Studio project to resolve assembly references. This solves some of the issues specific to t4 processing in Silverlight projects which use a different version of System assemblies. You can work around this issue using Visual Studio macro variables in the assembly directives now. For example, you can specify path to your DLL using something like this:

    <#@ assembly name ="$(ProjectDir)$(OutDir)MyAssembly.dll" #>

    Hope this helps


    Oleg
    Saturday, May 01, 2010 8:19 PM

All replies

  • Hello

    Did you try <#@ assembly name="BIG.Corpeum.ServiceReference" #>    (without the .dll) ?

    Best regards

     


    Jean-Marc
    Wednesday, April 14, 2010 12:03 AM
    Moderator
  • Hi Jean-Marc,

      Unfortunately proposed solution did not fix the problem :( .

      Actually, removing ".dll" even in VS2008 will break the template.

    ~Stefan

    Wednesday, April 14, 2010 2:10 PM
  • Stefan,

    In Visual Studio 2010, T4 no longer relies on the hosting Visual Studio project to resolve assembly references. This solves some of the issues specific to t4 processing in Silverlight projects which use a different version of System assemblies. You can work around this issue using Visual Studio macro variables in the assembly directives now. For example, you can specify path to your DLL using something like this:

    <#@ assembly name ="$(ProjectDir)$(OutDir)MyAssembly.dll" #>

    Hope this helps


    Oleg
    Saturday, May 01, 2010 8:19 PM
  • Thanks Oleg, it solved my problem!

    I have another issue with the assembly resolution. My assembly depends on System.Xml from Silverlight.

    To make it working I need to use full path:

    <#@

     

    assembly name="c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\System.Xml.dll" #>

    Is there a way how to reference it using Visual Studio Macro variables?

    Or at least how to reference 32-bit version of program files directory which will work on both 32 as well as 64 bit machine?

     

    Thanks, Stefan

    Tuesday, May 04, 2010 10:29 AM
  • I need to use my own types and also Entity Framework's "EF.Utility.VB.ttinclude" in a single T4 template.

    The proposed solution (using Visual Studio macros plus the assembly directive) allows me to use my own types, but it breaks relative path resolution in MetadataLoader.CreateEdmItemCollection. Using a relative path to the edmx file in another project of the same solution is the most convenient way for me of refering to it. When I include the assembly directive, MetadataLoader tries to find the edmx based on "C:\Program Files\Microsoft Visual Studio 10.0\Common7", instead of my current project path.

    Does anyone know why this happens and how to fix it?

    Thank you very much.

    José M.

    Monday, March 07, 2011 4:59 PM
  • Solved when I switched to hostspecific="true" in the template directive.

    Regards.

    Monday, March 07, 2011 5:15 PM