Scenarios to create packages are not smooth

Topics: General
Mar 24, 2013 at 8:50 PM
I'm trying to find out the easiest way to build my packages. I have two scenarios looking promising but each has a small trap:

1.) I want to use replacement tokens to use version, id and so on from the AssemblyInfo.cs. If I use the nuget pack command passing the .nuspec file I get the error that the replacement token has no value.

2.) If I run the nuget pack command passing the .csproj file it works locally on my dev machine and I can use the target-file to include it in the build process. But I use TFS and if I want to build this on my build machine the outputPath for the build is set to a different directory. It seems that the nuget pack command if using the csproj file is always searching for the assembly in the outputPath defined in the csproj file. I found no way to change this, also the BathePath Parameter has no influence. If I add the Project assembly in the file section of the .nuspec file it still tries to find it in the outputPath of the csproj.

I would be very happy if you could make her a small change (in my opinion). Either allow using replacement tokens also if you use nuget pack *.nuspec and take the values from the project file with the same name as the .nuspec file. Or allow to overwrite the path looking for the project assembly with the BasePath or an additional parameter.

That would make the good work you did since now practical by just fixing this last issue.

I know there are other Options like NuGetter but I'd like the idea to use the same mechanism for local and central builds.
Mar 25, 2013 at 3:48 AM
Having worked and talked with a lot of our (enterprise) customers, our recommendations are to avoid the PACK[csproj] command. It works locally, but as you've seen it first hand, that's about the only place. Tokenization has challenges as well, so we recommend either generating or modifying the .nuspec file your self at buildtime.

Take a look at this blog post for a a good workflow. It uses BuildMaster, but the same principles will apply.
Mar 25, 2013 at 6:09 PM
@TSchissler: The pack command accepts a Properties argument, which allows you to supply values for the $token in the nuspec file. Will it meet your needs?

@apapadimoulis: I want to know what other problems you encounter with the PACK [csproj] that you recommend against using it?
Mar 26, 2013 at 2:59 AM
@dotnetjunky I don't have a specific list of problems. Our enterprise customers have reported that PACK[csproj] is generally problematic outside of simple scenarios, and while it's entirely possible that it's a PEBKAC issue, our users are generally sophisticated.

However, our recommendation not to use PACK[csproj] is less based on reported problems, and more on enterprise process/workflow best practices. The proper workflow for packaging a dependency is:
  1. Label/Tag Source
  2. Get Source
  3. Build
  4. Run Unit Tests, static analysis, etc
  5. Package
nuget.exe fits only into step 5 (and obviously later when publishing). Of course it can also (try to) fit in steps 3 and 4, but with a sufficient amount of VBA, so could Microsoft Excel. FWIW, MAVEN (tries to) do not only 1-5, but steps 6+ as well. It fails just as spectacularly, which is we we also recommend MAVEN in Step 5 only as well.

nuget.exe is a specific type of hammer, and it doesn't pound in screws very well. Thus, our recommendation for PACK[csproj] is that it's fine for simple projects you build on your desktop, but it's inappropriate in enterprise development practices.
Mar 26, 2013 at 7:31 AM
@dotnetjunky: I know this Option but thet would mean I have to create a MSBuild activity which allows me to extract the version and other things from my assembly to pass it to my NuGet command. This is possible but I think the nicer and smoother way would be if you could make one of the above described Scenarios working. I think it should not be very hard to either using the overwritten outputpath (passed as a Parameter to the MSBuild command when building a csproj-file) to look for the Projects assembly or to ignore the Projects assembly if there is a <files> section in the spec file.

It's not that I can't get this working but I want to Point out that usability would not meet the expectation of new users at this Point and if you could improve this it would make it much easier for users to build their packages while using a central build Server without having to customize a lot of things.