6

I have a C# console app project which I am trying to turn into a Nuget package so that multiple projects within my team can call the executable from this project in an AfterResolveReferences step within the .csproj file.

I've created the Nuget package just fine with a .nuspec file that looks something like this:

<package ...> <metadata> ... </metadata> <files> <file src="bin\Release\*.*" target="tools" /> </files> </package>

This works and creates a Nuget package which contains my executable in the "tools" directory. The problem is the the containing folder includes the version number of the Nuget package which will change frequently. I'm trying to reference it like this in the .csproj file:

<Target Name="AfterResolveReferences"> <Exec Command="$(SolutionDir)packages\PackageName.1.2.3\tools\AssemblyName.exe" /> </Target>

When I include PackageName.1.2.3 in the path, it works as expected but this is obviously a very brittle solution. When I just use "AssemblyName.exe" I get "The command AssemblyName.exe exited with code 9009".

There's obviously a simple standard for doing this kind of thing which I'm not familiar with - MSBuild and Nuget aren't my strongest suits, so I'd be very grateful for any advice.

What I'm actually trying to achieve here is to create a TypeScript file containing interfaces derived from C# classes defined in my model project using the TypeLite.Lib package. The TypeScript file must be created before the web project is built, as TypeScript code in the web project depends on the interfaces contained in this output. I'm open to suggestions of more elegant ways to solve this problem but I would still like to know how to solve the referencing problem anyway.

Improve this question

1 Answer 1

Reset to default
8

The idea is that the NuGet package should be self-contained. That is, users should not need to add anything to the project file when using a nuget package.

NuGet packages can also contain build logic - if you put a PackageName.targets file into the a build directory, it will be automatically included into the project referencing the NuGet package. From there, you can define targets and would typically reference a tool by using $(MSBuildThisFileDirectory)..\tools\MyTool.exe.

This is important because the packages directory is only used for "classic" NuGet references via packages.config and not for the new-style PackageReference way of referencing NuGet packages, where all projects/solution share a user-level global package cache (no solution-local copies).

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Thanks Martin, that's really helpful. I'll try doing it this way, but I left out something which is now important. The parameters to MyTool.exe need to be defined by the consuming project (I was doing this in .csproj files but it would be better if it was in the consuming project's web.config). Is there a logical mechanism by which MyTool.exe can read the consuming project's config file?
You can always define/use custom properties that the project can set
Got it working using this method - thanks a lot for your help!

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.