Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate a NuGet package (and prevent the templates being copied into each consuming project) #25

Closed
wants to merge 12 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@ProductiveRage
Copy link

ProductiveRage commented Sep 29, 2014

Hi -

I've made some changes to try to organise things into a NuGet package. In doing so, I've made a couple of decisions that hopefully make things as easy as possible for someone to consume the package that hopefully aren't too controversial; I didn't include the templates in the package "content" folder so they're not copied straight into the target project. (I was hoping that this overlapped with the spirit of Issue #10 "The T4 template should not require source distribution"). I also removed the Immutable library reference from the main project, which required injecting the methods from the "CollectionExtensions" class into the generated types (if any of the fields are collection types). This does mean that there is duplication of code in the generated output but it means that none of the released templates have to reference the Immutable library, which they would have had to do with a hard-coded package location string. Now, if the consuming project has templates that utilise the immutable types then the templates there specify what version to use. For example,

<#@ template debug="true" language="C#" #>
<#@ Output Extension=".generated.cs" #>
<#@ assembly name="$(SolutionDir)packages\Microsoft.Bcl.Immutable.1.0.34\lib\portable-net45+win8+wp8+wpa81\System.Collections.Immutable.dll" #>
<#@ Import Namespace="System.Collections.Immutable" #>
<#
    this.Namespace = "Demo";
#>
<#@ Include File="$(SolutionDir)packages\ImmutableObjectGraph.1.0.0\templates\ImmutableObjectGraph.tt" #>
<#+
    class Message {
        Contact author;
        ImmutableList<Contact> to;
        ImmutableList<Contact> cc;
        ImmutableList<Contact> bcc;
        string subject;
        string body;
    }

    class Contact {
        string name;
        string email;
    }
#>

This could be tidied up so that the consuming project has a "base" template such as

<#@ assembly name="$(SolutionDir)packages\Microsoft.Bcl.Immutable.1.0.34\lib\portable-net45+win8+wp8+wpa81\System.Collections.Immutable.dll" #>
<#@ Import Namespace="System.Collections.Immutable" #>
<#@ Include File="$(SolutionDir)packages\ImmutableObjectGraph.1.0.0\templates\ImmutableObjectGraph.tt" #>

which the individual templates import with

<#@ template debug="true" language="C#" #>
<#@ Output Extension=".generated.cs" #>
<#
    this.Namespace = "Demo";
#>
<#@ Include File="BaseImmutableObjectGraph.tt" #>
<#+
    class Message {
        Contact author;
        ImmutableList<Contact> to;
        ImmutableList<Contact> cc;
        ImmutableList<Contact> bcc;
        string subject;
        string body;
    }

    class Contact {
        string name;
        string email;
    }
#>

That way, each project only has to have a single "text" reference to "ImmutableObjectGraph.tt" and to "System.Collections.Immutable.dll" (so that if either package is updated, there's only a single place that the version numbers must be changed).

I thought it would be really helpful to have this as a NuGet package (I know that I looked for one almost as soon as someone pointed me to your work) and I think the approach I've taken is the least invasive for someone pulling in the package.

You can generate a new .nupkg file by building the project in Release configuration and running "NuGetBuild\BuildNuGetPackage.bat".

I'd be interested in hearing your thoughts! I wasn't so presumptious as to publish it right now, but I am eagerly anticipating its availability assuming you're ok with these changes - and I'd be happy to publish it if you're happy for me to do so! :)

ProductiveRage added some commits Sep 29, 2014

Removed the System.Collections.Immutable reference from the templates
This meant duplicating the CollectionHelpers methods in the generated
classes (if any fields use collection types) but it will make it easier
to NuGet-up since it won't have a text reference to a particular binary
version
Change the ImmutableObjectGraph.tt to expect to be part of a NuGet pa…
…ckage

This "primary" template will include files from a NuGet installation
while the ".ForTests" template can be used in the Demo and Tests
projects
A single "base" template per-project avoid repeating NuGet references
The Demo project has a "BaseImmutableObjectGraph" template which
references the "primary" ImmutableObjectGraph template and the
System.Collections.Immutable NuGet binary to illustrate how repeating
them can be prevented (and if either NuGet package gets updated, there's
only one place per project to fix by hand)
Demonstrate ignoring of "The field '{0}' is never used" warnings in t…
…emplates

It's not essential to flag these warnings as ignore-able, but without
doing so there are 48 warnings in building the solution
@AArnott

This comment has been minimized.

Copy link
Owner

AArnott commented Nov 20, 2014

Fixed by 6138d4b

Thanks for your contribution. I had already done this in a non-public fork of this repo which I could finally make public. If your pull request adds value over what we now have in this project, please feel free to update your pull request and submit.

@AArnott AArnott closed this Nov 20, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.