Reputation: 16186
I'm working on a C# project using Visual Studio 2015, with NuGet for package management. For one reference, I'd like to temporarily use a local build while I'm iterating on a fix, rather than the released version. What's the best way to accomplish this?
If I were using an SVN external, I'd drop the new locally built copies into the external reference's folder, and be set. Other package management software (like CocoaPods) would allow me to point to a local directory to resolve the reference. With NuGet, it doesn't look like there's any mechanism for this.
When I try dropping my new DLL over the package reference inside the packages
folder, I get inconsistent behavior in Visual Studio. My build will fail with hundreds of errors, most of which go away from the Error List quickly. I'm ultimately left with a warning telling me it could not resolve the reference to the assembly I'm trying to replace (though the properties of the reference do indicate it's finding my new version).
Upvotes: 58
Views: 28437
Reputation: 995
DNT (DotNetTools) is pretty up to date and has commands to switch from packages to local project references and back again.
dnt switch-to-projects
dnt switch-to-packages
https://github.com/RicoSuter/DNT#switch-to-projects
Upvotes: 10
Reputation: 20967
In .csproj
project file:
<ItemGroup Condition="'$(Configuration)'=='Debug'">
<ProjectReference Include="../../../Library1/Library1.csproj" />
<ProjectReference Include="../../../Library2/Library2.csproj" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)'!='Debug'">
<PackageReference Include="Library1" Version="1.0.0" />
<PackageReference Include="Library2" Version="1.0.0" />
</ItemGroup>
In development: project compiled in debug mode, so the project reference will be used.
In production (CI server, docker container): project compiled in release mode, so the package reference will be used.
Upvotes: 9
Reputation: 837
I found the following workaround useful for me:
First I disable "NuGet Package Restore" from the context menu of the Solution.
After that I go to the %HOMEPATH%\.nuget\packages
folder, and search for the package I want to replace. From this package I take the version number, and use this exact version number to build the dll I want to exchange.
After that I can exchange the dll in the packages folder with this newly built dll. Building the project now uses this new dll.
After having this set up once, I can easily build new dlls, and copy them to the packages folder.
Upvotes: 30
Reputation: 622
In VS2019, this is how you can conditionally switch on build between project reference and package reference. We use this for our docker containers
Open your project solution "Solutions\Bookstore\Bookstore.sln" that has the project "Bookstore.csproj" that will reference the nuget
Add a solution folder for example "nuget" and add existing project "Solutions\Library\library.csproj"
Add conditional item group to the project file "Bookstore.csproj"
<ItemGroup Condition="Exists('..\..\Library\library.csproj')">
<ProjectReference Include="..\..\Library\library.csproj" />
</ItemGroup>
<ItemGroup Condition="!Exists('..\..\Library\library.csproj')">
<PackageReference Include="library" Version="1.0.0" />
</ItemGroup>
In solution explorer, right click Bookstore solution > properties > configuration properties. For the configuration 'Release' uncheck the project 'library.csproj'. Now when your code is built in debug, it will build the project reference. When it is built in release it won't try to build it.
When we publish make sure you use 'Release'. This works because when you publish it will not be able to find "Solutions\Library\library.csproj" from the path we configured in Bookstore.csproj "..\..\Library\library.csproj".
You don't have to use docker for this to work but as an example here is the commands our dockerfile will run
WORKDIR "/Solutions/Bookstore"
RUN dotnet restore
RUN dotnet build -c Release -o /app
FROM build AS publish
RUN dotnet publish "Bookstore.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
Upvotes: 18
Reputation: 2634
We've had great success using this tool. It's easy to use and works.
Upvotes: 10
Reputation: 3549
You can create your own Nuget feed (simple local folder + some configurations)
Read more here Hosting Your Own NuGet Feeds
Upvotes: 16