I have a Visual Studio project that I would like to distribute as a template to other developers across the organization. I've been able to package the project into a NuGet package, but I'm a bit lost on how to distribute this across the organization.
At this point, I'm considering copying the NuGet package to a shared location and setting up a process that'll run when developers sign in to install the package via dotnet new -i <path_to_nuget_package_file> but I suspect there may be a better way to accomplish this.
Does anyone have any ideas?
Related
I have a list of nuget packages that I only use for development. I know in node you have devDependencies. Is there a similar way in visual studio? What's important for me is to control which packages gets carried over to production.
My team mate figured out the solution to this which is using conditional assembly reference. So the package will still be restored when the package is build but it won't be included in the deployment of the final build.
https://heejune.me/2016/02/17/c-conditional-assembly-reference/
I was wondering about the right way to do this. For example, let's say you have a number of projects (part of a solution) that uses boost. Let's say you want to put the boost package in the solution so the entire thing is more portable.
How do you do that? Do you install boost in a directory within the solution? Can you reference it using relative directories, so it isn't portable?
Under Linux, for completeness, one could just store a tarball in the code under control, but it was left to the developer to bring it out and install it. I'm wondering how this is done (best practices) under visual studio.
[NOTE: I understand this might make the solution large, but the benefit would be a development environment that would run immediately without a bunch of package installs for each development system accessing the code.
In this case you could use the nuget package manager in visual studio to add the nuget boost package to your solution then boost will be available to the projects that need it. You can then enable package restore so that whenever the solution is built if the boost files are missing from the solution then nuget will restore them on build.
If you haven't already you will need to install the nuget package manager plugin for visual studio.
Where the package isn't available on nuget there are a number of options; you can build the package and then reference the assembly that's been built - you just store assemblies you need in a references directory. If your using source control software Svn or tfs possibly git ( I don't know) then you can store these in source control and then include them in the target solution via links. The final option I can think of is you can build the package into a nuget package and then store the result in your own private nuget store visual studio allows for this. Which solution works for you will depend on the size of the project, development team and the source control software you use.
Is it possible to manually install, or perform an offline installation of, SpecFlow? I can install the VS plugin for SpecFlow, but it seems the only way to install the SpecFlow dll is online through NuGet.
My team is behind a firewall without internet access so I am curious to know if this is possible.
Any info/suggestions is greatly appreciated.
If you have the VS extrnsion you don't need the NuGet package. However using the Nuget package and adding it your source tree would ensure that specflow tests can be run even on machines without VS such as build servers, and other developers machines that do not have the SpecFlow extension installed.
Also, you can quite easily add a new NuGet source which can be configured to any folder, either locally or on your internal network. So if you can the SpecFlow extension msi into the office, you can also download the NuGet and make it available.
We sell source codes for some of our apps and try to keep dependencies to a minimum. Currently, when customer gets the source codes, he can open a solution and start coding right away, the only prerequisite is to have VS 2010 or more.
We considering using Nuget. Is it safe to manage project dependencies with Nuget even if most of our customers don't have it installed?
I can see that Nuget saves all needed libraries in the "packages" folder and adds references to them, so it appears pretty safe to me. I've done some testing: uninstalled Nuget and tried to build the project, all worked fine, but I only have VS2012.
I couldn't find any accurate info on this topic nether in official documentation, no on other web-sites. So, does anyone know for sure, is it required to have Nuget installed in Visual Studio to work with nuget-enabled projects?
If it is your intention to redistribute those packages as binaries bundled with your sources, then NuGet is not required. However, if you don't plan to redistribute those packages, then the customer must have NuGet installed.
<opinion>
I don't think it's unreasonable to make NuGet a requirement for the use of your sources. It's easily installed into VS2010 and present by default in VS2012. Microsoft is increasingly relying on it as a core part of the tool chain. Resistance is futile. :) </opinion>
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.