Nuget restorating is good when using CI in VSTS. However I am using some extensions like SQLite Runtime in my project. Is there any way to include those extension dlls other than referencing them in the project?
Besides referencing them in the project which actually is the most recommended way.
You can also manually install the extension on the build agent. Just like how to use it in your local environment. Make sure the environment on the build agent is as same as your local.
Check the extension and dlls in source control. Even though we do not suggest to manage dlls for source control in TFS.
Some packages (like redis for instance) have a "tools" folder which allows you to pull the "runtime" from nuget.
If your tool is not shipped as a nuget package you'll have either to:
- Include the tool on the source control (not the best thing if you want to keep the repo as small as possible)
- Install the tool on the build machine (only possible if you have your own agents and you're not using the hosted agent)
- Have a script to pull it from the web without relying on nuget (again really depends on the tool and if it has a "run without installation" version)
Hope that helps
Related
Using csx scripts in Azure Functions I can use the Project.json file to install nuget packages, but when I'm using fsx scripts the packages aren't installed (the log console never shows the Starting NuGet restore message). The only way I found is installing locally and uploading the dependencies. Am I missing something?
I think that the current execution model for F# in Azure functions does not support project.json. There is a work in progress PR to improve F# support that will enable this.
For now, I think there are two options:
Install the packages locally and upload them to Azure (as you are doing)
If you're deploying via git, then I think the deployment lets you run deployment script (in the same way in which Azure WebSites let you run a deployment script).
I have not tested the second approach with Azure functions, but I think it could work. For example, see the F# Snippets' deployment script which calls a build script that starts by using Paket to restore dependencies. This way, you need just paket.bootstrapper.exe and paket.dependencies with paket.lock to specify your NuGet dependencies.
I am trying to grasp Release Management vNext and dsc configuration 'management' (how to manage DSC configuration files). In the 'Deploy Using PS/DSC' dialog box while editing a vNext Release Template
Why is PSScriptPath relative?
Does it really mean, that I somehow have to get my scripts I want to use relative to my current drop folder? What is the best way to do achieve this? I want to be able to do:
Have a separate git repository for configuration files
Reuse configuration files across different projects
I've read a promising article Packaging DSC configurations for Visual Studio / TFS Release Management vNext but it seems to be out dated and some kind of hack from my point of view.
How does Microsoft want us to use this? How to achieve reusable configurations in a separate repository?
Thank you
Use a submodule to your separate configuration repository, then ensure the submodule is initialized during the build. You can then copy the configuration scripts to the build drop folder as part of your build script.
The reasoning is that your deployment scripts will evolve over time, and that evolution should be something that is captured. If you ever need to redeploy an old version of your software, that old version shouldn't be deployed using new scripts -- it should be deployed using the same version it used initially.
I have a website, a windows service, and some shared class libraries in a single Visual Studio solution. I use Octopack on both the website and windows service, and on my machine these builds work as expected.
When using the TFS Build Server, the website nuget package is generated as expected, but the windows service nuget package contains all files from the website, as well as the service. E.g. it includes the _PublishedWebsites folder as well.
This is because TFS uses a single location to build projects.
What is the best way around this?
I know this question has since been closed, but I cam across this issue and solved it in a different way.
My solution is compromised of a number of websites and windows services and had the same issue of the OctoPack created nuget packages including all the solution assemblies from the 'pooled' output folder when building with Team Build. The reason the nuget packages get all the assemblies is OctoPack uses the outdir msbuild argument as the location to include assemblies from.
The way I got around it was to use the msbuild argument GenerateProjectSpecificOutputFolder=true. This instructs Team build to create a folder for each project in your output folder in the same way Visual Studio uses the bin folders under each project when building locally.
My build definition msbuild arguments looks like:
/p:GenerateProjectSpecificOutputFolder=true;RunOctoPack=true;OctoPackPublishPackageToFileShare=\\<NugetServer>
I currently just push the packages onto a shared folder but the OctoPackPublishPackageToHttp and OctoPackPublishApiKey parameters can also be used.
The benefit of this solution over the one above is you don't need to specify the files to include the nuget package.
Hope this helps someone.
I ended up using this nuget package to ensure the console app built to a seperate directory on the TFS server.
https://nuget.org/packages/PublishedApplications/2.1.0.0
I then had to specify in the nuspec file, which files should be included for the console app. e.g
This works and I can now deploy using Octopus deploy.
The downside of this apporach is that the PublishedApplications build only works on the TFS build server, so I can't build the project locally in release mode. Still looking on how to overcome this.
Background
I have the following components:
My local solution (.NET 4.5) which makes use of NuGet packages.
A PowerShell build script in my solution that has targets to build, run unit tests, to Web.config transforms, etc.
A build server without an internet connection running CruiseControl.NET that calls my build script to build the files. It also serves as the (IIS7) environment for the dev build.
A production server with IIS7 that does not have internet access.
Goal
I would like to utilize NuGet packages from my solution and have them be stored locally as part of source -- without having to rely on an internet connection or nuget package server on my build and production servers.
Question
How can I tell MSBuild to properly deploy these packages, or is this the default behavior of NuGet?
Scott Hanselman has written an excellent article entitled How to access NuGet when NuGet.org is down (or you're on a plane). If you read through this article, you'll see at the end that the suggestions he makes are primarily temporary-type solutions and he goes out of his way to say that you should never need the offline cache except in those emergency situations.
If you read at the bottom of his article, however, he makes this suggestion:
If you're concerned about external dependencies on a company-wide
scale, you might want to have a network share (perhaps on a shared
builder server) within your organization that contains the NuGet
packages that you rely on. This is a useful thing if you are in a
low-bandwidth situation as an organization.
This is what I ended up doing in a similar situation. We have a share which we keep with the latest versions of various packages that we rely on (of course, I'm assuming you're on some type of network). It works great and requires just a little work to update the packages on a semi-regular basis (we have a quarterly update cycle).
Another article that may also be of help to you (was to me) is: Using NuGet to Distribute Our Company Internal DLLs
By default, Nuget puts all your dependencies in a packages/ folder. You can simply add this folder to your source control system and Nuget will not need to download anything from the internet when you do your builds. You'll also want to ensure that Nuget Package Restore isn't configured on your solution.
You'll have to make a decision; either you download/install the packages at build time (whether it be using package restore, your own script, or a build tool that does this for you), or you put the /packages assemblies in source control as if they were in a /lib directory.
We've had so many problems with using package restore and NuGet's Visual Studio extension internally that we almost scrapped NuGet completely because of its flaws, despite the fact that 1 of our company's 2 products is a private NuGet repository.
Basically, the way we manage the lifecycle is by using a combination of our products BuildMaster and ProGet such that:
ProGet caches all of our NuGet packages (both packages published by ourselves and ones from nuget.org)
BuildMaster performs both the CI and deployment aspect and handles all the NuGet package restoration so we never have to deal with massive checked-in libraries or the solution-munging nightmare that is package restore
If you were to adopt a similar procedure, it may be easiest to create a build artifact in your first environment which includes the installed NuGet package assemblies, then simply deploy that artifact to your production without having to repeat the process.
Hope this helps,
-Tod
I know this is an old discussion, but how in the world is it bad to store all the files required to build a project because of the size?
The idea that if a library is not available that you should replace it is crazy. Code cost money and since you don't control the libraries on git, or in nuget, a copy should be available.
One requirement that many companies have is an audit. What if a library was found to steal your data. How would you know for sure if the library is removed from NUGET and you can't even build the code to double check.
The one size fits all Nuget and git ways of the web are not OK.
I think the way Nuget worked in the past, where the files were stored locally and optionally place in source control is the way to go.
I am busy trying to configure a build server for TFS2010. My project has references to Microsoft.practices. The build fails because it can't find these references on the build server - because I haven't installed the Microsoft.practices on the build server.
I was wondering if installing it on the build server is the best way to do it, or is there another way to add the 3rd party references when configuring the build server?
I know I can just install it, but I'm looking to follow best practices here.
Regards,
Byron Cobb
I would keep the referenced third party dlls in TFS within your project. Structured similar to:
/ProjectSolution
/ProjectA
/ProjectB
/lib
/3rdPartyLibA
/3rdPartyLibB
Now edit your build definition, in the Workspace tab, in the Working folders section, make a reference to you /lib folder in your project. The build agent will retrieve the 3rd party libs and use it for compilation.
A simple way is to check-in third party assemblies in TFS. You can add an additional folder to your TFS with a fixed relative path to your project. Then add references from there. This way you don't need to install 3rd party assemblies in your build agents. Additionally you don't need to edit your build definition too.