We've got about two dozen projects, which all use different NuGet-packages and a bunch of Telerik WPF libraries, the latter are usually added by GAC, which on its own does not add a hint path to the csproj-File. (Good)
As soon as we use Telerik's upgrade wizard to simultaneously upgrade the references of all projects, Telerik starts copying the files to a local lib folder next to the bin folder and adds hintpaths, which do not exist on other developers machines AND need to be discarded before pushing to Git every time. (Bad)
BTW: We regularly get the same problem (regarding hintpath) with the Spire NuGet-Package.
Now we came up with some suggestions, which we internally valued differently and therefore did not come to an accord:
Keep discarding the chunks containing the hint path
Ask Telerik to fix the wizard
Check the libraries into Git
Add Telerik libraries using their NuGet server
Create a Libaries-Path we manage by hand, maybe as a network drive
What's other peoples approach to handling those issues?
I'd go for "Check the libraries into git".
Rationale: when a developer (or CI system) checks out your project from source control, he should be able to build it right away without having to install dependencies like GAC assemblies.
You need to use NuGet for that, it's the easiest and most organized way, you should not have a problem for other developers when you install a new package as long as you are committing package.config file, in this case any one will do a build of the solution visual studio will automatically restore NuGet Package.
Make sure to set your NuGet settings as below image shows:
Don't use the Telerik wizard. Add the Telerik dependencies using NuGet. They have a private NuGet repository. See the tutorial here.
Related
I'm coding on a project that has several Azure-based applications, as well as several Windows services, etc. Needless to say, it's just a bunch of individual applications that are deployed out to Azure, or elsewhere, and expected are all expected to work together.
We use Nuget for our underlying library project versioning. Every feature or change results in a bump to the Nuget version, a package published to our private Nuget server, and a subsequent update to every other application that needs the update. This is currently a tedious manual task, but is not even my most immediate source of frustration.
The thing that I struggle with the most, currently, is while doing development on a feature that requires changes across the entire set of applications, from bottom to top, and having to constantly push out Nuget packages and update Nuget packages just to even develop and debug.
Prior to using Nuget, we may have just added all of these projects as direct dependencies on disk, which removes versioning but instantly lets me develop against my local changes.
Now with Nuget, I can't develop against local changes without pushing out a new package.
Is there a workflow that I'm missing that would allow me to still use Nuget but also be able to make changes and work locally without having to push and pull Nuget packages all the time?
Can I somehow develop against local projects, but also somehow have the project dependencies know to use the Nuget packages?
I ran into this issue when setting up a shared NuGet repo for my company. You can set up local a NuGet feed and 'publish' just by dropping files to a folder. This is extremely useful for local testing before you're ready to publish to the shared repo.
Also, NuGet uses semantic versioning. I find it useful to have pre-release versions by using a tag like MyLibrary.1.0.0-prerelease-12345 so you can still have incremental builds, but most other apps will not be notified of the changes until you create a major release such as MyLibrary.1.0.1. This could require you to make some changes to your DevOps process, but it allows multiple developers to test your package before 'officially' releasing it.
If your issue is that you want to be able to easily update multiple applications locally and test those changes. I have occasionally found it useful to create a single solution file encompassing all my projects so I can quickly open, update, and build everything in one Visual Studio instance. However, this solution is not particularly scalable, so you might be better off writing PowerShell scripts for automation.
Update Another solution that you might find useful is NuLink. I have never tried it so I can't actually endorse it, but it purports to provide similar functionality to npm link (and actually uses symlinks just like npm does).
Given the projects are all in the same repo, just use project references instead of package references.
When you pack a project, NuGet will convert project references into NuGet dependencies, and the dependency version will be the same as what the other project is if/when it is packed.
Check this answer, where you could:
build the dependency's code locally to produce DLLs.
replace the DLLs in your machine's nuget cache folder corresponding your dependency with the local DLLs produced in the previous step
That's a quick way to see changes locally without publish-consume cycles
The setup: I've created a library targeting .Net Standard 2.0 in VS 2017 and this library uses NuGet to reference a 3rd party driver and manage its dependencies. So far, so good.
The next step is to create an application that uses the (shared) library, in this case a console app targeting .Net Core. I can, of course, add a reference to the DLL(s) that form the shared library. That compiles but doesn't run because the 3rd party stuff is missing. I could of course just copy all required DLLs to the application but for obvious reasons I'd rather use NuGet.
I'm not very experienced with NuGet, never used it in this constellation and having read articles like NuGet cross-project dependency I'm getting the impression I need to fiddle with the application's project file in order to get the library in a complete form but surely that can't be the way forward.
So my question is - is the problem on the side of the library, i.e. do I need to build or export in a particular way, or on the side of the application which, IMHO, shouldn't need to know that level of detail about some library it consumes.
Any help much appreciated!
I'm sharing a large, complicated library this way with several other solutions.
First, set up your library. Right click on the library's project name and choose Properties. About halfway down you'll see a tab labeled Packages. You can use that to auto-generate the NuGet package every time you rebuild the project. Just increment the version number. I use four position version numbering -- the first three are semver-style (major release, minor release, patch release), and the fourth one I increment manually for each new build.
I recommend creating a folder on your drive or network specifically for your local NuGet packages. You can create folders under that for each project. Then you point your debug and release build output to that project folder, and the NuGet package will be generated there, too.
Finally, back in Visual Studio, go to Tools -> Options -> NuGet Package Manager -> Package Sources and add that top-level folder as a package source.
From there it's simple -- open your NuGet dependencies in your consuming app. There's a drop-down at the top right where you can choose the package source. It will automatically search all the child folders and find whatever packages you've created. Now when you tweak your library, it's just a single click to update the client apps.
We have 1 solution that contains all of our shared assemblies. Currently we are referencing these assemblies based on relative path (../../../../../SharedSolution/bin). It would be nice to create a nuget package (or a few based on various dependencies) to reference these assemblies so I can get easily update and I don't have to worry about having the exact same directory structure as everyone else on the team and all the other benefits of nuget.
However, let's say that when I'm working in my ProjectASolution, I realize that I need to make a change or add a shared class to SharedSolution. In my ProjectASolution if I have referenced the assemblies from SharedSolution with a nuget package, but I want to test my changes to SharedSolution before committing them, is the only way to copy the assemblies from the SharedSolution bin to ProjectASolution's packages folder?
Since we are frequently editing classes in SharedSolution, I'm beginning to think that nuget might not be the right way to share these assemblies.
Another possible solution is to add the projects from SharedSolution as links to any of my ProjectSolutions that need to reference them. Is this a better alternative?
Is there a better way to share these assemblies than relative path? Is there an easy way to test changes made on a dev machine to a nuget package?
You can build a pre-release package. Only developers who set their nuget to use pre-release packages will see them, everyone else will be still using the latest stable.
A good explanation and How-To can be found on the NuGet Pre-Release Package page.
To address the questions you raised in your comment:
You can build nuget packages locally, based on the .nuspec file which is usually next to the .nupkg file in the packages folder. You can use NuGet Package Explorer to do so in a GUI.
To distribute them, you can store the pre-release packages on a network folder. Any developer interested in the pre-release package can add this network folder to their nuget sources and can then use the Visual Studio-integrated nuget as usual. Or you can just copy them the .nupkg file.
You should be using as much self-contained testing as possible for an assembly before publishing a new package. Ideally, anything you would be putting into a NuGet package would be fully covered by unit tests and, if necessary, some kind of test app.
Also, if you're going to use NuGet, I would look at splitting up some of those assemblies if possible. It's easier to maintain references and track real updates to packages if they're in logically separated sets rather than one mega package.
I need to get my external dll dependencies (automap, others ...) into a situation where I can build them on my build server. I would also like to get then them into subversion, so the build server can pick them up.
So I'm new to the whole 'lib' folder thing. I've searched Google, but it seems it's kind of assumed, there are no basics of what to do here. The books I own don't go into it. It's been a long time since I had a mentor at work, or even someone I could ask questions of ... and I'd really love to understand the fundamentals of what I should be doing here.
I write in .Net, use Jenkins as my CI server (new to that) and msbuild (new to that too). I'm hearing svn:externals (don't compute), NuGet ....
Please help!
Suppose my solution is called MySolution and is stored in C:\MySolution, then I have have three directories for binaries, all managed by source control.
vendor the source code of third party frameworks. If needed they are built and signed (with my key) and treated as if the code was my own. This is sometimes necessary to "fix" defects in the framework or debug their source to understand why it fails.
src\packages modules managed by nuget (I wished to combine this with my "lib" folder, but that isn't yet supported)
lib compiled libraries for which I don't have the source and that are not managed by nuget.
(I have omitted folders like "src", "sample", "setup", "documentation" and "scripts" to keep the answer specific to the OP).
The recent months I started to create my own nuget packages for "packages" in the lib folder so I can migrate all of them to "packages". Its published to a private nuget server. It also simplify managing the binaries across solutions.
I use to use externs, but they pose a branching nightmare after a while because you have to branch and pin the external dependencies to. With nuget this is no longer needed.
I would definitely avoid putting binaries in source control. You'd be far better off creating your own nuget repository containing your preferred versions of packages and either using nuget restore or some other way of "rehydrating" your dependencies for building. I use a simple batch file called nuget-update.bat which just looks at all packages.config files and gets any dependencies it finds.
It seems that you posted a sequence of questions on the same topic. I recommend NuGet, as it becomes critical and promoted hard by Microsoft. However, many old libraries are not available there, and you may still need to keep a lib folder. My open source project #SNMP is a good example,
I tried to use as many NuGet packages as possible, and even stepped up to maintain some of the dependencies, such as DockPanel Suite.
I have an issue with creating an easy solution for my build system, based on mono.
Current situation is that I keep my referenced libraries inside the git repository, which is not good, for many obvious reasons.
What I want to achieve is something like what NuGet provides - automatically download dlls from the Web, put them in some directory and forget about them.
I want to do this at build time, so it would not require any additional actions with downloading libraries etc. The best option would be an msbuild (xbuild on mono) task, but I want it to be system independent, so the popular one, executing NuGet.exe, is out of question (consider parallel mono installations, etc.).
I've tried Pepita project, but it's... wrong. No, really, it is, it has too many design mistakes to be easy to use or repair. To make a proper configuration would require a serious rewrite of the whole project.
What I would love is a library, that would employ NuGet.Core library and be available as a task. If such a lib is not there, I could use any solution, that would download a nuget package and unpack it to a directory specified in .csproj.
Even better, it would be nice if such a library could resolve dependencies without specifying them explicitly in packages.config (or similar) file, e.g. if I want to include Castle.Windsor I don't want to include Castle.Core in my config file.
I know about the OpenWrap project (with NuGet Gallery), it looks promising, but I can't find the solution where I would just put a constant set of libraries in my repo once, modify csproj files, some configs and have it done.
I can tell you that OpenWrap at the core has everything built-in to do what you want. Everything you can do with the openwrap-shell is also available to be called from msbuild. So, it seems to me that you would just need to add a before build hook to call out to openwrap to perform an "update-wrap". Several months back I actually looked into doing something similar. AFAIR I actually wrote an msbuild script to call openwrap tasks, but didn't really hook them into the normal build process.
I don't know exactly what you mean with "put a constant set of libraries in your repo once"? For OpenWrap, all you need to do is maintain the "openwrap descriptor" for your project. That file contains all direct dependencies of your project (with or without restrictions on version numbers). (Indirect dependencies are pulled in automatically) Are you wondering about how you get started when you have a bunch of binary dlls to start with? I can tell you what I did. Basically, I do not use any NuGet packages, I created OpenWrap packages for everything. I also created OpenWrap packages for all our binary dependencies (some of which are open-source). This is really super simple: you fill in correct dependencies in the OpenWrap descriptor and specify that the package must only contain the given dlls. We had a bunch of binary dependencies, but once you start packaging them, it's definitely not that much work.
If you want to see an example, you can check this one:
http://code.google.com/p/ppwcode/source/browse/dotnet/External/Apache.Log4Net/trunk/Apache.Log4Net.wrapdesc
That is all you have to do to package your binary dependencies. This is a package I created and we currently use it in the company where I work. I know Log4Net is probably available as a NuGet package, and I could probably use that. The advantage of creating those binary packages myself, is that I have full control over the packages, over the version numbering of the packages, over how a big project is split over several smaller packages and so on.
As an OpenWrap repo, you can use a folder on your local filesystem, or a folder on a network share. What we use, is actually a webdav repository that we mount locally on a drive (using Windows 7). This works fine for us and also allows us to specify who has read and write access to the repository.
You mention mono.... well, that might be a problem: the currently released version of OpenWrap (2.0.2) does not run on mono AFAIK. But the good news is that Sebastien Lambla has been working hard to get OpenWrap to run on mono+xbuild for the new version that is going to be released very soon: 2.0.3. No alpha/beta builds available yet, but you can build from git. (In that case you would need to build both openwrap-shell and openwrap). Sebastien Lambla, who created OpenWrap, normally keeps an eye on questions on StackOverflow and will probably be able to give you a more complete answer on the mono status.
Btw, where I work, we are using OpenWrap already for over a year. Back then we compared both NuGet and OpenWrap, and at that moment OpenWrap was way way way ahead of NuGet. Basically, to me, NuGet was not a tool for dependency management, but a tool to assist you in Visual Studio to pull in binary dependencies from a remote server (meaning: copy dll from remote server to local folder and add reference to local dll in project file). In the mean time, NuGet has been playing catch-up with OpenWrap and has added functionality that already existed in OpenWrap. There are in my opinion only 2 things that NuGet has over OpenWrap and that is integration in Visual Studio (aka overview of remotely available packages and click-click-click adding of packages) and the fact that it is maintained by Microsoft people (AFAIK). Both things are just political: it's easier to convince people with a pretty interface and microsoft support. Personally, however, I think that OpenWrap is technically superior and I think it's really a pity that it doesn't get the attention that it deserves.