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)
Related
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.
I have a VS (2015) project. I see there's a "References" section in the Solution Explorer view of my project that includes things like System.Core. I'm assuming these are .dlls that have been added to the project?
I can also right-click on the project file (again in the Solution Explorer) and select the option to "Manage NuGet Packages". I know the NuGet allows me to add external code to my project (e.g. external .dlls and associated files).
What's the difference between adding a reference to my project and adding a .nupkg to my project? Is it just that .nupkg can contain a whole bunch of other things aside from a .dll (e.g. documentation)? Why would I use one or the other?
What's the difference between adding a reference to my project and
adding a .nupkg to my project?
NuGet essentially does not differ from manually adding references, and ultimately adds references to the project. It is a tool that automatically adds assemblies to us and manages them, effectively improving the efficiency of our development projects.
For more details, you can check the document about nuget:
Put simply, a NuGet package is a single ZIP file with the .nupkg extension that contains compiled code (DLLs), other files related to that code, and a descriptive manifest that includes information like the package's version number. Developers with code to share create packages and publish them to a public or private host. Package consumers obtain those packages from suitable hosts, add them to their projects, and then call a package's functionality in their project code. NuGet itself then handles all of the intermediate details.
Because NuGet supports private hosts alongside the public nuget.org host, you can use NuGet packages to share code that's exclusive to an organization or a work group. You can also use NuGet packages as a convenient way to factor your own code for use in nothing but your own projects. In short, a NuGet package is a shareable unit of code, but does not require nor imply any particular means of sharing.
.
Is it just that .nupkg can contain a whole bunch of other things aside
from a .dll (e.g. documentation)?
Yes, NuGet package could include specify files in the package.
Why would I use one or the other?
Nuget provides several additional benefits:
it automatically configures your projects by adding references to the
necessary assemblies, creating and adding project files (e.g.
configuration), etc.
it provides package updates
it does all of this very conveniently
I'm sure that once you use it, you'll realize that it has many benefits.
Check Why use NuGet for more details.
Hope this helps.
We are currently migrating our source control to Visual Studio Online. A feature we had in our old system (SourceGear Vault) was to share projects between solutions. Although this created a folder for our Framework project in each solution it kept it up to date when changes were checked in.
This is useful to us as it allows us to work on the Framework code in all the Solutions that are using it. I know its better practice to just compile the dlls and reference them - at this point in development we want to continue having full code access and debugging in all the solutions using this core framework.
Any help very much appreciated.
You have a few equally valid options for handling shared projects:
Reference the same project from each solution that needs it.
This gives you full control over the source code of the shared project while you work on the consuming solution, and may allow for easier debugging.
The downside here is that maintenance and releases may become trickier if Solution A is being released on Thursday, but Solution B is being released in 3 months and is in the middle of a huge refactoring cycle that has significantly modified Shared Component X, and Shared Component X isn't stable enough to be released.
Reference shared components from an internal NuGet repo.
You set up your release pipeline to push the shared components into NuGet as part of your release process (ideally, using a purpose-built release management tool... Microsoft Release Management is what I have in mind here) -- you check the code in, project gets built. Release process packages it up and pushes it into NuGet as a "prerelease" version. You reference the latest version in anything that needs the latest version.
If you need to reference a known-good, stable version, you just make sure your project is configured to pull a specific version from NuGet.
When you're done, you've tested the shared thing, and you know everything is good, you approve the prerelease version, and the same binaries are repackaged into a "stable" version.
The downside here is that there are some additional software requirements, configuration, and training for your team. This would be my recommended approach.
Check binaries into source control.
I don't recommend this one -- you end up bloating your source control repo (and if you're using Git, it's an explicitly stated anti-pattern -- never put binaries into Git, it causes long-term severe performance problems), and it's never exactly clear which projects are using which versions of which assemblies. It's a maintenance nightmare.
(1) is the best approach if you're releasing everything in lockstep and don't have to worry about maintaining separate versions.
(2) is the best approach if #1 is false.
(3) is the best approach if #1 is false and you're a time traveler who is posting from 2006.
Have you considered implementing Symbol Server and Source Server indexing with the check-in binaries or NuGet repo approach? This allows you to easily get back to the source while debugging and it's coming from a single known location. Visual Studio Online and Team Foundation Server have built-in support for helping you out with getting this setup during your build process. Here's more information in a write-up here: Source Server and Symbol Server Support in Team Foundation Server and Visual Studio Online
Thanks for the responses. We actually found a solution that works well for us. We branch our framework project into the implementation projects when we want access to the code base. If not we just use the DLLs
If it is then altered and checked into the implementation project it can be merged back with the other Framework branches easily when ready.
This probably wouldn't work well if the Framework code was being developed heavily, as it is now its only undergoing small additions and tweaks so wont be plagued with merge issues.
I have to agree with the majority. I just ran into the same issue. I implemented the Nuget Gallery Site on the internal network. It was a pain to implement, but once implemented, it's easy to use. I created a class library project that implements ADO.Net and the EntityFramework. I bundled it into a NuGet package and uploaded it to the internal NuGet gallery. From there I was able to add a package source to the internal NuGet gallery and grab the package that I uploaded. Very simple and convenient.
I set up the NuGet Gallery with Visual Studios 2017. FYI: Make sure that building the project isn't part of the Publish. It will not render with a ViewHelper.cshtml error.
I created the projects with Visual Studios 2015. I ran the command prompt as administrator. I also had to copy the NuGet.exe file into the directory where the project file existed.
Check out the below links for more information.
NuGet Gallery
Hosting NuGet Gallery
Create and Publish Package
Creating a Package
Create .Net Standard Package
What is the best way to share dll libraries between projects, through VS2010? For example we have made a generic helper library that is useful in everything. However, we need more than one library to be included (which is a separate project in TFS) so branching is not suitable.
We are using Team Foundation Server 2010 for source control. Is there maybe a simple way to integrate these libraries into a new project, so the new project can come "fully buffed" very fast?
What we do now is go through each project, build them, store the dll files, add a new project then throw them in the Bin folder, which is tedious work when you have many libraries.
Have you thought about hosting your own NuGet feed? I use a pre-build script for NuGet for each of my projects which downloads packages for me before the project is built, and, I assume, keeps them up to date.
I don't think that there is some TFS-based solution for sharing binaries between projects. However you can use NuGet to do it for you. Create nuget package for each project (you can create TFS build definition to do it automatically) and publish it to network share. Than add this share as NuGet feed.
It has been common practice to check nuget packages used in a solution into source control. With the new package restore feature of nuget 1.6 it is no longer necessary to check packages into source control. However, this leaves your projects dependent on nuget.org. There may come a time when a needed package is not available on nuget.org and not available locally in your organization, without which you would not be able to build your project.
Are there any enterprise solutions for backing up nuget packages used in projects in a centralized fashion? One scenario is to have an enterprise nuget proxy server, from which projects get their nuget packages. This proxy server can backup the requested packages in some fashion, like storing them on a backed up folder and checking the content into a shared source control repository. Another scenario is to have the backup logic done automatically on each developer's machine.
In summary, what are some good automated options for backing up nuget packages?
You should look at Artifactory from JFrog (http://www.jfrog.com/): they recently added support for NuGet. Artifactory can act as a central cache for multiple NuGet feeds. I spoke to the development team at a conference earlier this year, and they're really switched on.
There is also ProGet, although I have not used this: http://inedo.com/proget/overview
I don't know of any existing backup solutions, but this is definitely something we'd like to solve at some point. A couple of ideas come to mind.
Use DropBox to backup the packages directory into another location.
Run your own instance of NuGet.org locally and have your CI server populate the local one with installed packages.
Use MyGet.org to host a private feed of all the packages your team has installed.