Example
C# Project A is stored in internal Git Repository A
C# Project B is stored in internal Git Repository B but references Project A
Question
What is a simple way for Project B to reference a Project A?
Options considered
Install, configure, and deploy internal NuGet server
Check Project A's dll into git and use npm since it has the ability to add a dependency directly to a git url (including version)
Use git submodule
Use git subtree
Copy Project A's dll manually into Project B
I'd suggest Nuget, but you don't need a server. Nuget can work from a simple local folder. Setting it up takes one minute.
Set up a git repo for the packages and clone it on your machines. In VS, Tools->Options->Nuget, configure a new package repository pointing to your local folder.
Related
I have to build several dozen repositories using Visual Studio Team Services. I have two problems.
How to build repository wich has other external .dll in reference. Can I download it somehow in definition step from sftp or other place?
These repositories have to be build with diferent sets of .dll references. For now we build them changing properties of the project in VS, now we would like to have this functionality in our build definition in VSTS. For example: we would like to build repository with 12.1, 12.2, 12.3 sets of external .dll reference and produce three Artifacts after one pull request.
I have no experience with VSTS, can anybody give me some advice?
In VSTS build, you can only build the sources from one repository for a build. So there are two options you can use:
1. Add external dll into the current repo you need to build.
You can add the dll in your current repo, and then refer the dll from your current repo. Then commit and push the changes and build by VSTS.
2. Add the repo which has the dll you are referring as a submodule for your current git repo.
By adding submodule, you can use the external dll directly. One thing to note, you just need to select checkout submodules in your VSTS build defintion.
I am currently in a situation where our team is creating a nuget package DLL A and consuming that package in an application Application B. A and B are maintained as separate Git repositories.
Right now my process is:
Make changes to A
Commit and push to prerelease branch(CI is run which generates pre-release package on our Artifactory instance)
Nuget update B
Consume Changes in B
While nothing in this process takes terribly long, it does add up over time. Previously A was part of the solution of B and we could just use project references to quickly iterate.
My question is, is there a better way to approach this process for creating and consuming Nuget packages? I would like this to work for multiple team members who each have their development folder structure setup the way they like it. We have considered using local nuget packages, but I am unsure how to set that up so it works for everyone on the team consistently (and that still requires manually updating B's nuget packages).
I am using Visual Studio 2015 Update 3 with projects that all target .net 4.6.1. Mainly I am working with Class Libraries and WPF Applications that use nuget package.config to manage nuget references.
I'm trying to make my .Net project work with Artifactory. So far I've uploaded the reference assemblies(.dll) files to artifactory using Jenkins. Now to build my solution, I want to refer those uploaded reference assemblies(artifacts) from artifactory, rather than referring them from the local path.
I tried using the MSBuild artifactory plugin, but it has a partial support for Jenkins.
Is there a way to do this?
You can not reference dll directly from Artifactory. To use them as dependencies in your project you have two options :
first one is to download them locally before your build (you can
setup a prebuild step for that)
second one is to create a nuget
package containing these dlls, to upload this nuget package to
Artifactory (this is where the MsBuild Artifactory plugin can help
you) and use it as a nuget dependency within your project where the
nuget feed used by Visual Studio will be configured to reach
Artifactory nuget repository.
I have several WCF and WebAPI services as well as MVC websites in a visual studio solution. Currently, we are creating WebDeploy packages for these services and websites to deploy to IIS. I'm starting to look into Octopus Deploy for deploying our services and websites instead of WebDeploy. However, Octopus Deploy uses Nuget packages to deploy.
I'm trying to figure out how I can easily create a Nuget package that contains all the files that would normally be published into a WebDeploy package. This may not be all files in the project directory or the bin directory. I found this blog post describing how to package a csproj into a Nuget package during the build, but I found that the resulting package didn't contain any of my dependency dll's. I realize I could write a nuspec for each of these projects manually and include exactly the files I want, but I'm looking for a more automatic way as this would create more maintenance when my project changes.
Does anyone out there know a good way to generate a nuspec or Nuget package that contains only the files needed to run the application, similar to the way publishing to a WebDeploy package only includes the files it needs?
Octopus Deploy has a CLI called "Octo.exe" that can package up your application into a NUPKG.
You will need to install Octopus Tools which you can download from https://octopus.com/downloads
Please see http://docs.octopusdeploy.com/display/OD/Using+Octo.exe for the documentation and how to use it.
A good example to use Octo.exe is part of a Continuous Integration pipeline when the build has successfully passed you call it to package the application and send it to the Octopus server.
After some playing around with Visual Studio, MSBuild, and TeamCity, I discovered a method that works for me. My issues was that I did not want to package up all the files in my project directory, only those that are necessary to run the application. WebDeploy handles this quite nicely as one of the options when publishing. I already have settings in my csproj file that will create a WebDeploy package on build, but this is a zip file and I don't want the zip file in my Nuget package.
I found 2 ways to deal with this:
In TeamCity, I set up a new Build Configuration that will package any nuspec files I have and publish the resulting Nuget packages to my Octopus Deploy Nuget feed. I figured out that I can use the existing WebDeploy package that gets created by my CI build configuration as an artifact dependency and TeamCity can actually unpack the zip file when grabbing the artifacts as part of that dependency. Then my nuspec file references the entire folder structure that was extracted from the zip file and packages it into a Nupak.
I was able to modify my csproj settings to use a specific publish profile I generated in Visual Studio that would perform a WebDeploy package to file system. This would result in the same folder structure as is in the zip file from #1, but simply copied to a directory. Then my Nuget build configuration could simply grab those dependencies and package them the same way as in #1.
I decided to go with option #1 as it would require minimal changes to my existing csproj and CI build configuration, and it would not break our current method of deploying using WebDeploy.
For a github hosted open sourced C# project which is also available via NuGet, how should one organize the source? Specifically:
should the .nuspec file be in the github repository?
should the .nuspec file be in the same folder as the .csproj file?
how about the NuGet package tree (the /lib, /content stuff), since is generated, should it be in git?
My thinking is that the NuGet part is separate from the github hosting, as in the project source are available but the .nuspec is not, since the publishing in NuGet is not an open source operation per-se. None wants that every fork to build and publish a new NuGet package, so that the open source Foo package ends up in the gallery as 'Rick's Foo' vs. 'John's Foo' vs. 'Alice's Foo' etc.
But on the other hand I do want the github source depot to act as a one-stop repository for the project, if I open my other laptop and enlist from there, I should be able to build/package/push w/o recreating the whole NuGet infrastructure from scratch (ie. only enter my API key, nothing more).
These two requirements are contradicting each other, Did I miss something obvious?
I would do the following:
Commit the .nuspec file next to the .csproj file
Add a nuget.config file which moves the packages folder a level up.
Enable package restore in the solution and do NOT commit the content of the NuGet package repository
Create an msbuild file (or whatever build vehicle you like) which has:
a "build" target which builds the source and creates the nuget package
a "publish" target which pushes the NuGet package to nuget.org and takes your API key as a parameter.
I personally maintain the version number of the nuget package in the .nuspec file and manually update it when I do a "release". This way I can tag the exact release I pushed to the NuGet feed.
With this setup a build in Visual Studio does not produce a NuGet package but all tools are available in the repository to do so.
The Folder Structure looks like this:
.\Docs\ ==> not in source repo
.\Packages\ ==> not under source control
.\Src\ ==> git repo here
.\Src\MySolution.sln
.\Src\.gitignore
.\Src\MuRules.ruleset
.\Src\build.proj ==> msbuild file to build everything.
.\Src\MyProject\MyProject.csproj
.\Src\MyProject\MyProject.nuspec
.\Src\MyProject\nuget.config
.\Build\ ==> not under source control
.\Build\Debug\
.\Build\Release\
.\Build\Publish\
Be aware of this bug in the Package Restore feature, it will ignore the packages location you configured. http://nuget.codeplex.com/workitem/1990 ==> This is fixed in Nuget 2.7
On nuget v2.8, I just need to modify .gitignore and add:
packages/
This will exclude the nuget packages folder from committing. When you build the new checked-out source code, the packages would be downloaded and restored. Make sure package restore setting has been enabled but I think it's been enabled by default on v2.8.