Projects for package target installation

Jun 9, 2011 at 4:52 PM
Edited Jun 9, 2011 at 4: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?

Coordinator
Jun 9, 2011 at 4:58 PM

I didn’t understand this statement “that the nupkg unsurprisingly has the nothingness that is built to Client.MVC3.dll”.

If I were to guess, I think you’re running into the following problem: http://nuget.codeplex.com/workitem/936

Phil

From: dotnetchris [email removed]
Sent: Thursday, June 09, 2011 8:53 AM
To: Phil Haack
Subject: Projects for package target installation [nuget:260791]

From: dotnetchris

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 current version. The only time I would alter Client.MVC3 is that I introduce a breaking change or new feature addition that results in a major version increment 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?

Jun 9, 2011 at 5:28 PM
Edited Jun 9, 2011 at 5:29 PM
Haacked wrote:

I didn’t understand this statement “that the nupkg unsurprisingly has the nothingness that is built to Client.MVC3.dll”.

 If I were to guess, I think you’re running into the following problem: http://nuget.codeplex.com/workitem/936 

 Phil

The Client.MVC3 project is completely empty other than the tools folder /config files and nuspec file. So when you build, you do obviously get a DLL out of it Client.MVC3.DLL. This DLL contains nothing because there are no code files in the project to actually compile to a DLL. So the DLL is just a waste of space and I don't want it included and then referenced in my projects that would consume Client.MVC.nupkg.

Is there somehow I can opt it out of automatically being added? Or should I just pack client.mvc3.nuspec instead?

Coordinator
Jun 9, 2011 at 5:33 PM

Ah, I get it. You are simply using the csproj to define a dependency and some tools etc, but we expect an assembly. In fact, I don’t think you can prevent that assembly from being generated.

It’s funny, because I think it’s been a longstanding request of ours to the VS team to allow projects that don’t produce assemblies. In this particular case, I think you should use a nuspec.

Jun 9, 2011 at 5:55 PM
Haacked wrote:

Ah, I get it. You are simply using the csproj to define a dependency and some tools etc, but we expect an assembly. In fact, I don’t think you can prevent that assembly from being generated.

 

It’s funny, because I think it’s been a longstanding request of ours to the VS team to allow projects that don’t produce assemblies. In this particular case, I think you should use a nuspec.

If you have a codeplex issue for the VS team about the no assembly project I would certainly vote for it.

It makes sense the project parameter expects to use the project output assembly directly, I was just wondering if there was a flag or something I could stick in the <files> list etc to make it ignore it. I do find it fairly reasonable that I just need to treat this project as basically a file system nuget package to create the tools deployment setup.

Coordinator
Jun 9, 2011 at 6:15 PM

Ha! VS doesn’t use CodePlex for VS tracking. They use the connect system and I don’t think this is logged there.

Jun 9, 2011 at 6:54 PM
Haacked wrote:

Ha! VS doesn’t use CodePlex for VS tracking. They use the connect system and I don’t think this is logged there.

That connect site is absolutely abhorrent for giving feedback. 90% of the time I can't even find a relevant place to submit feedback in it. In the rare cases I've been able to find what I want to leave feedback for I've went to it and it's said "we're not taking feedback on that product".

So now down to the single digit % of times that I actually was able to leave feedback succsesfully I think of the 2 or 3 things I ever submitted both were closed as not reproducable within days even though multiple people commented agreement. And i'm pretty sure 1 of those were closed with "we just don't care".

So from the experience I've taken from Microsoft Connect, that site isn't really for leaving feedback. That Microsoft puts products on it to put a barrier up to not get feedback on it. Just so they can push people off with "go file a bug report on connect" and knowing people will give up due to frustration.

Coordinator
Jun 9, 2011 at 6:56 PM

Mind if I forward your feedback to the Connect folks?

The sad truth is, different teams treat Connect differently. The ASP.NET team reviews every bug in there. We can’t always fix all of them, but we do review them in a timely manner (at least we try to now).

NuGet uses CodePlex because we develop in CodePlex. We don’t promise we’ll fix everything either, but we do accept well written, well tested, contributions.

Jun 9, 2011 at 7:30 PM
Edited Jun 9, 2011 at 7:33 PM
Haacked wrote:

Mind if I forward your feedback to the Connect folks?

 

The sad truth is, different teams treat Connect differently. The ASP.NET team reviews every bug in there. We can’t always fix all of them, but we do review them in a timely manner (at least we try to now).

 

NuGet uses CodePlex because we develop in CodePlex. We don’t promise we’ll fix everything either, but we do accept well written, well tested, contributions.

Yes that is the real reason I expressed my feelings towards connect. It's something I've always wanted to communicate with Microsoft, I even went to connect to try to report this before and couldn't figure out where to submit this feedback to which was the last time I ever thought about connect until now.

After having said this, I actually think when I tried to submit this information to Microsoft about connect specifically is when I got the "we're not taking feedback on this product". Which would be incredibly ironic.