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.
Related
I need your help.
I'm developing an msbuild task that performs certain actions upon msbuild.
I want my users to be able to download and install a nuget package and once the package is installed the build task will be part of the build process.
I know how to release a nuget package and i know how to includes a custom targets file together with the nuget, what i don't know is how to add the import statement to the csproj upon nuget installation:
Is there a way to do so or am i asking for too much?
Thanx!
Gilad
The docs aren't in the easiest to find place, but here's a link to the docs on including MSBuild props/targets files in your package.
Basically, you put the file in the package in the location build\<tfm>\<package_id>.props. For example build\netstandard2.0\MyPackage.props. If you want your build targets to be included in all TFMs, you can use build\<package_id>.props, but if your package also contains other assets like lib/ or contentFiles/, the "no-TFM" build files will cause "asset-target fallback" to fail, so if your package has only net472 libs, and the build files, a project targeting netcoreapp3.0 will get only the build assets, none of the net472 assets. If your build files are in a TFM folder, then NuGet's asset target fallback will select both the lib and build assets. So, I strongly encourage everyone to always use the TFM folder.
The docs need to be improved, but the table explaining lists build, buildTransitive, and buildMultiTargeting. Projects using packages.config only use build assets under build. Projects using PackageReference only use build and buildMultiTargeting assets when the project references the package directly. Assets under buildTransitive get selected when the package is pulled in transitively, rather than directly. The difference between build and buildMultiTargeting is complex. If you understand the concept of "inner-build" and "outer-build" in multi-targeting SDK style projects, that's the difference (build is inner-build), otherwise only use build.
I should update the docs to have this information.
I have generated some nuget packages containing .pdbs with the following:
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
I have verified the .pdbs are within the .nupkg generated in the lib/*/ folder next to the dll's.
However, when I consume these nuget packages in Visual Studio 2017, it only extracts the .dll's and not the .pdb's. Leaving me unable to debug into the package.
What am I doing incorrectly?
Since you can make sure the .nupkg contains the .pdb file. please make sure both the projects are in debug mode.
Consuming a nuget package locally sometimes has some difference from installing it from nuget.org. The .pdb source won't be found in solution. By default, the .pdb will locate under path like :C:\Users\xxx\.nuget\packages\PackageName\xxx.
Update:
If the nuget package project and the project which consumes it is on the same machine. The AllowedOutputExtensionsInPackageBuildOutputFolder property is enough. Since you have source files on same machine, and the debug engine can easily find it so that you can step into it.
But if for a scenario like this: You developed the nuget package. And share it to other team members. To make them can Step into you should embed the xx.cs files into the .nupkg.
Under this circumstances, the AllowedOutputExtensionsInPackageBuildOutputFolder may not work. I can't find a way to embed source files using it. You may need to use a nuget pack command like this issue. Actually, the way Stephan packed the project is correct. I've checked it work and will embed the source files and .dll and .pdb into the .nupkg. Of course, in this way you need to add the path to source files repo by Solution=>Properties=>Debug Source files:
In addition: You can add the nuget pack command in a post-build event, so that every time you build a project successfully, it will package for you.
Also, you can consider source links as source control so that you won't configure the source path by Solution=>properties.
I want to write that C# code convert-nunit-3-nunit-2-results-xml-file, but despite the added nuget package i'm missing the dll in my project.
I see it in the tool's directory of the package cache, but missing it in my project.
What do i overlook?
My project is at present for .Net Core 2.1. Is my issue therefore related to this: Add support for net standard ?
I'm new to .net and don't understand all the differences so far.
As zivkan explained, the package is a tool. In fact, it's an extension to another tool, the NUnit engine package. The NUnit engine knows how to find and use the extension.
NUnit does not publish a package that is intended for use by your code as a library, because we would then have to support it as a library in addition to it's use as an extension to NUnit.
However, NUnit's MIT license allows you to use the source code, which you can find at https://github.com/nunit/nunit-v2-result-writer
Since the code has not yet been ported to .NET Core, you would have to do that yourself.
You didn't overlook anything. Not all NuGet packages are libraries.
NuGet has conventions on how files must be packed in order to use various features. For example, files in the content or contentFiles get copied into the project directory, or build output, depending if the project using the package uses packages.config, or PackageReference. If the package author wants to give you a library that you can use in your code, they must put the library in the lib directory in the nupkg (technically it could be in ref, but those don't get copied to build/publish output, they're only used at build time). The tools directory is, unsurprisingly, intended for tools packages. It's often used by unit test runners, or in this case, a report generator.
So, since the package puts the dlls in the tools directory, this means the package author intends the package to be a tool to assist you during development, but not as a library for you to use in your code. You could try contacting the package author to see if they have published another package with the same dll, this time in the lib directory, so that you can use it your project.
Otherwise you'll need to find a solution that doesn't rely on NuGet bringing you this dll as a library. One option is to have a packages.config file that extracts the package in a solution packages directory, and then you use a dll reference to the dll. Your build script would then need to first restore the packages.config file before building your project. Another option is to check in the dll into your source control management tool, if the dll's license allows that, and again have a dll reference to it.
I have a VS2015 solution with 6 projects in it. I'd like to create a nuget package out of it but:
the project is for internal use only, so I don't want to publish it online
It should include the source code (is it possible?, not a strict requirement)
It should be the final artifact, can I choose a directory where to have such package?
thanks
You can publish nuget in your private host with https://github.com/themotleyfool/Klondike.
you can use nuget Package Explorer to create nuget package. https://github.com/NuGetPackageExplorer/NuGetPackageExplorer
You have multiple options. Either you can use command prompt or Nuget Package Explorer.
In order to publish you can use Nuget official server or private Nuget server. I recommend Nexus Nuget server.
For publish official one, you need to create account and obtain api key.
You can find detailed usage in here.
For including source code, there is no such a thing in official one. Because it aims ready to use artifacts.
You can add your dll, dependencies, extra files such as configs, html etc
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.