We are experimenting with nuget for our visual studio projects. However, we only (or at least mainly) use nuget for our own external references, and we store them in a local repository (network share). What I would like to know is how to handle the whole debug/release situation.
Concrete (simplified) situation:
We have a main project that has references to two shared components that we developed ourselves. These shared components are also used in other products of our company
When we build the main project (azure pipelines), we build the debug and release versions of the project. However, we can only specify a single nuget package for each external reference.
What we want to accomplish to to use the debug version of the shared components during the debug build, and the release version during the release build. However, these are (as far as I know) actually different packages.
What is the way of tackeling this issue? Is there, for instance, a way to include both the release and debug versions in a single nuget package? Is it possible to have to different nuget configurations for different build configuration settings?
I've found Best practices with Nuget: Debug or Release?, however this topic doesn't really address my issue. This thread is more a discussion about whether to publish debug or release versions to a remote server. We want to publish both and use both in a private repository. We have no intention of sharing our libraries with the rest of the world.
A NuGet package will normally hold just a single set of assemblies for a particular target framework. It is not really designed to ship a debug and release version since you are publishing the NuGet package to be consumed by other users. Normally you do not publish a debug and a separate release version of your application to end users.
You may be able to workaround this by using a custom MSBuild .targets file in the NuGet package that has its own references and configuration information. You can use this .targets file as an extension to your project. It will be imported so you can define the references as you need based on the configurations defined in your project. It is not ideal but it should work.
Related
I have a repository in Azure DevOps which hosts a solution/project providing common library code for our environment and is worked on by one team (and me).
A few other repositories in the same project are applications that require the use of this common library. I have both repositories setup in VS22 and can use the repository switcher to quickly switch between the 2 solutions to edit/compile them - essentially working on them both at the same time.
Currently, in the application project, I reference the common library by browsing to it's debug binary path and selecting the dll, but this means when I build the application in release, it still pulls in the common libraries debug dll.
Is there a more elegant way to reference this other project from a different repository like you would if both projects were in the same solution, so it uses the appropriate dll?
Just curious, per my title above.
I am leaning towards a nuget package-like style, where the dev team can continuously update libraries (dll's) and deploy them to a central location e.g. Nuget. Then, have project reference the dll depending on the version that's been deployed in a central location e.g. Nuget.
Deploying the dll's in a shared folder won't work.
Please advise, thanks.
Actually, nuget is the best way.
Pack
You can work with your teammates to maintain the same nuget project. When you are creating a nuget package or make some changes, you can just set different nuget versions for them to pack them as nuget package(.nupkg). These are different pack functions(non-sdk project uses nuget.exe, new-sdk projects use dotnet cli, msbuild.exe can work with both of them but note in non-sdk projects, it works with non-sdk projects with PackageReference).
Push
When you finish it, you could push the nuget package into a a shared folder, or push into an azure devops feed.
Use
You just send the full path of the shared folder or the feed url link(they should give your teammates sufficient permissions)
And anyone who wants to use it should set the link into nuget package sources, and then they can install it to use it.
Besides, if there is a subsequent update operation, as a nuget maintainer, you modify the lib project, after that, set a new version for it, any descriptions to tell others there is a new release updated version during pack process.
Then, push the new version into the feed to let others could install it.
We are using Team City 9.1.5. Our main application is very old and complex, and over the years we have had to write several utilities to support customers. The utilities need to reference application components, and multiple versions of the utilities are maintained to correspond to different application versions.
To avoid creating a new release of the application every time a utility needs to be updated, we are using the Team City NuGet feed to host versions of our application's dlls. These are then referenced by the utilities in Visual Studio, etc.
The original solution was to create a separate build configuration for NuGet packages for every released version of the application. These are manually triggered to reduce the number of packages for a specific version of the app (i.e. I don't need a package for every build, just stable).
Over time, the number of supported versions of the application has grown, and so has the number of NuGet package build configurations. I am trying to consolidate these separate build configurations into a single build configuration with multiple build steps - one step per version. But when run, Team City will only publish the latest version of a package from a single configuration. Examination of the configuration's artifacts show that all all of the different versions are built and retained, but only the latest is published.
When I break the exact same build steps out into multiple configurations, one build step/configuration per version, the artifacts all show up again.
Is there a way to get Team City to publish all of the artifacts from a single configuration, even if there are multiple versions of the same package?
Per JetBrains, "Unfortunately it's a known bug in TeamCity: https://youtrack.jetbrains.com/issue/TW-40363, please vote for it."
My solution for now is to go ahead with the separate build configurations, although that will add maintenance overhead and "noise" to the TeamCity projects page.
We are also discussing an alternative solution of using one build configuration and pushing to a separate nuget package feed other than Team City's.
Neither of these options is desirable as both will require additional resources to implement.
I found that nuget seems to always install packages under the folder of the visual studio project.
It is not feasible for me because the package that I'm going to distribute contains huge amount of data. I don't want to make a copy of that whenever I add that package to a new visual studio project.
I want that data to be shared between projects. Since it is shared, if one project removed that package, the data should stay there until I explicitly tell the system to remove it.
Is there any way that can deal with this kind of problem?
I heard that Maven installs packages in a global location and it doesn't have such a problem. How about using Maven to install .NET libraries, is that possible? What would be the potential problems?
To upload and store your .NET artefacts you'll need a Maven repository manager like Nexus, Artifactory or Archiva. Good news is that these are capable of storing files of any type.
If you don't fancy converting your build process over to Maven, I'd recommend the following answer on using Apache ivy with MSBuild. All Maven clients appear to cache their downloads for use across projects (They're basically intelligent downloaders)
The upcoming 2.0 version of Nexus promises integration with NuGet. I'm expecting better .NET support from Maven in the future.
We have a couple of private "Enterprise Services" DLLS that are used in all our Websites for authentication, logging, etc. Since they are private, we also control the versioning and source of these DLLs. Our historic (error prone) steps after creating File | New Project include
Add the "Enterprise Services" project
Add a reference to above
Edit web.config sections such as Authentication, HttpHandlers, etc...
NuGet will automate the above process
I just came across NuGet (bundled in MVC3) which allows me to download and install VS2010 packages from a privately hosted server, and automate the config settings that previously would have made manually.
Question:
Does it make sense to publish my dll into a private NuGet server?
Will I lose the ability to debug and step into this dll if I need to?
What other things should I consider if the rest of my project is based in TFS?
I agree with marcind: having a private feed make sense.
My 2 cents are that you don't need to configure a private server: configuring your VS to target a shared folder is enough for distributing the packages and it will be easy to update with your TFS builds: just create the NuGet package and drop it into the shared folder.
Keep in mind that, for the latest NuGet bits that I tested, the client (both the console and the gui) does not look into other feeds for locating the dependecies so it will complaint that it can't resolve them automatically: you'll have to install them by hand.
Yes, it makes sense for you to have a private NuGet feed
I'm not sure about stepping into the dll, but if you provide PDBs in your NuGet package as well as the library sources on a share (and then configure VS to know where those sources are) then you should be able to step into the code just like you can today for the .NET framework itself.
NuGet was designed to work well with projects that are mapped to source control so hopefully there's nothing else you need.
#Ghidello NuGet will resolve dependencies automatically as long as you aren't using a specific respository (the package source dropdown in the console is set to All instead of your private repo)