5

I have a solution with an application project (ASP.NET Core) and multiple library projects. I want to separate some of the library projects into a separate solution and turn them into NuGet packages.

With the libraries in the same solution I could of course simply edit something in a library, run the application and see how it works (and debug, if necessary).

However, when I turn the libraries into a NuGet package, the application references the packages from our private NuGet feed instead of the project file.

My question is: is it possible to locally "override" the package reference and use the local source code instead? That way I could still edit the libraries and see the effects in the application. This is a lot easier than having to publish a new package for every small change (especially when trying to fix an issue or implementing a new feature).

qrjo
  • 101
  • 2
  • 6
  • Usually once you publish and install once you just have to copy the exe file from build folder to deploy folder. The publish updates the dll on deploy machine so it is compatible to build machine. If you are not adding any new libraries to the source then the dlls do not need updating. – jdweng Jan 14 '21 at 13:32

3 Answers3

3

DNT (Dot Net Tools) does this. You can specify which packages to switch and where they are.

See the 'switch-to-packages' and 'switch-to-projects' command line switches.

Its a bit fiddley as (when I last tried) you had to create a config file that holds the mapping, and it seems to be easy to break the switching. But its something.

https://github.com/RicoSuter/DNT

I've not tried it, but maybe you can use it to switch to packages on a commit for the build server to work correctly? (Or to ensure the references are correct in source control?)

BJury
  • 2,526
  • 3
  • 16
  • 27
2

If you want to use nuget in your project and debug, even modify the source files of the nuget packages, this is not a good choice because you should build the nuget project(generate the new changed dll) and repack it as a nuget package, then reinstall, to enable the changes. It is too complex.

Once you install the nuget, no matter how many changes you make, it’s useless. The nuget installed at this time is the version you made before any changes. No matter how you change it, it is the previous version. The version stays at that timestamp, unless you repackage the project. Generate nupkg and update the nuget version.

So nuget is not a good choice for your situation, you should use ProjectReference.

Directly use the ProjectReference to reference two source projects, build at the same time, and get the changed parts at the same time.

ProjectReference could cross two different solutions.

Add this on the main project:

<ItemGroup>
     <!--add any nuget project'csproj file like this to debug its source code-->
      <ProjectReference Include="..\xxx\xxx.csproj"> 
      </ProjectReference>     
</ItemGroup>

If the proejct is out of the solution, you could directly use the full path of the nuget project's csproj to connect it.

Mr Qian
  • 21,064
  • 1
  • 31
  • 41
  • Yeah, I was afraid of that. I could always temporarily change the PackageReferences into ProjectReferences, but that's of course not ideal to do it manually every time something needs to be tested. – qrjo Jan 18 '21 at 12:28
  • You can create a new configuration called `nuget_debug` and then use PackageReference with that the `condition="'$(Configuration)'=='nuget_debug'"`. And use `debug` configuration with `ProjectReference`. You can switch configuration to test these two modes easily. Also, do not forget to pack your nuget project every time and set it [self-incremented version](https://stackoverflow.com/questions/23754398/how-do-i-auto-increment-the-package-version-number). Also, use `` to get the latest version. – Mr Qian Jan 22 '21 at 09:25
  • Yes, I considered that option. It's quite a bit of work to setup all those references unfortunately. But it's the best solution I've found so far. – qrjo Jan 25 '21 at 09:55
  • You have to use this. A good method requires a big price. Once you are done, you will enjoy its dividends later. – Mr Qian Jan 28 '21 at 07:14
1

I'm not sure what you mean by "override" but you can always add the library project to your ASP.NET Core solution and reference it like normal project references. A project referenced within a solution doesn't have to be physically placed in the same folder as the solution itself.

This, however, does require that any developer on the project has both GIT repositories cloned locally (given your two solutions are located in separate GIT repos) in order to be able to build the ASP.NET Core solution. But I don't really see that as a downside.

Xerillio
  • 4,855
  • 1
  • 17
  • 28
  • By override I mean something set locally that doesn't get committed to the application's git repo. The application has to work without the library source code on another machine (pulling the package from the NuGet feed). – qrjo Jan 14 '21 at 15:05
  • @qrjo I highly doubt you'll find functionality like that in VS. I think that's a too specific use case to fit into a commonly used IDE. Either you'd need to build your own VS extension or create some scripts you can run to toggle between a package or project reference. – Xerillio Jan 14 '21 at 17:04