Jun 9, 2011 at 3:52 PM
Edited Jun 9, 2011 at 3:54 PM
I have a solution I'm working on converting to nuget. The basis of it comes down there is a Client and a Server.
The Client needs to have different installation configuration whether it's MVC3 vs webforms (unsurprisingly).
This has lead me to creating Client.MVC3 and Client.WebForm projects that each contain nuspec files that set dependency relationships to the Client project. The Client.MVC3 project also has the Tools folder and other related install specific config.
I'm not sure whether this is the standard thought process on how to setup the differences between install targets or not, so let me explain my rationale on doing it as this. By creating a stand alone Client.MVC3 project, I am breaking the dependency on the
installation aspect out of the Client and making it solely dependent on Client.MVC3. This (atleast is my goal) leaves me free to update Client any number of times and never need to touch the Client.MVC3 project or it's version number. The only time I would
alter Client.MVC3 is that I introduce a breaking change or new feature addition that results in a version increment in the Client that requires specific configuration.
This leaves me in a strange predictment that when I pack Client.MVC3.csproj -Configuration Release -Verbose -OutputDirectory .\bin\ that the nupkg unsurprisingly has the nothingness that is built to Client.MVC3.dll and adds it to the package.
What would be best to avoid this, should I just pack by the spec file instead of the csproj for this case?