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.
Related
We are considering a move to Azure DevOPS/TFS and we have built a prototype workflow which seems to work well.
The only outstanding thing from our current CI process to replicate is the triggering of builds based on nuget package updates.
Our build pipeline is a tree, where some libraries which generate nuget packages generated at the top of the tree are used as dependencies in other libraries downstream.
Using team city one of our build steps inspects the dependencies of a solution, identifies the topmost level dependencies and adds them as nuget build triggers ensuring that the next time a successful build of a dependency occurs the downstream library is triggered as well.
How can that be replicated in Azure Dev Ops?
I think you might be after something like NuKeeper:
NuKeeper automates the routine task of discovering and applying NuGet
package updates.
NuKeeper will compare the NuGet packages used in your solution to the
latest versions available on NuGet.org, and:
List available NuGet package updates on .NET code on the local file
system or on a GitHub server.
Apply NuGet package updates to .NET code
on the local file system.
Make pull requests containing updates to
code on a GitHub server.
Image stolen from Shayne Boyer's blog.
I am having trouble understanding the fundamentals of octopus deployment. I am using octo.exe with the create-release and deploy-release commands. I am also using the octopack plugin.
I am getting an error but that's not really the point - I want to understand how these peices fit together. I have searched and searched on this topic but every article seems to assume the reader has a ton of background info on octopus and automated deployment already, which I do not.
My question is: what is the difference between using octopack by passing the octopack argument to msbuild and simply creating a release using octo.exe? Do I need to do both, or will one or the other suffice? If both are needed, what do each of them do exactly?
Release and deployment as defined in the Octopus Deploy Documentation:
...a project is like a recipe that describes the steps (instructions) and variables (ingredients) required to deploy your apps and services. A release captures all the project and package details so it be deployed over and over in a safe and repeatable way. A deployment is the execution of the steps to deploy a release to an environment.
OctoPack is
...the easiest way to package .NET applications from your continuous integration/automated build process is to use OctoPack.
It is easy to use, but as Alex already mentioned, you could also use nuget.exe to create the package.
Octo.exe
is a command line tool that builds on top of the Octopus Deploy REST API.
It allows you to do much of the things you'd normally do through the Octopus Deploy web interface.
So, OctoPack and octo.exe serve a different purpose. You can't create a release with OctoPack and octo.exe is not for creating packages.
Octopack is there to NuGet package the project. It has some additional properties to help with pushing a package onto the NuGet feed, etc.
octo.exe is used to automate the creation of releases on the Octopus server and optionally deploy.
Note: a release in Octopus is basically a set of instructions on how to make the deployment. It includes the snapshot of variables and steps, references to the versions of the NuGet packages, etc.
octopack is a good starter, however I stopped using it some time ago with a few reasons.
No support for .Net 2.0 projects (and I needed to move all legacy apps into Octopus)
didn't like it modifying the project files (personal preference)
Pure nuget.exe was not much more work for me.
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
I am attempting to fully automate the deployment of a simple assembly onto two application servers (which have the Tentacle services installed), and I'm running into a few challenges.
What I have achieved:
I can create a NuGet package with /p:RunOctoPack=true.
I can manually upload (publish?) the package to my built-in feed on the Octopus Deploy server.
I can deploy the packages to both my application servers using the Octopus Deploy portal.
I can infer from the post (OctopusPublishPackageToHttp in TFS Service) that I should be able simply put all of the following on the Process/Build/Advanced/MSBuild Arguments box
/p:RunOctoPack=true
/p:OctopusPublishPackageToHttp=http://octoserver:8081/nuget/packages
/p:OctopusPublishApiKey=API-MYKEY.
However my builds are returning the error
Exception Message: Access to the path 'C:\Builds\1\Experiments\CIBuildDef\bin\ConsoleTibcoMefClient1.1.0.0.0.nupkg' is denied.
(type UnauthorizedAccessException)
With this assembly (a simple .NET Class Library). The builds are all being dropped into the same path (C:\Builds\1\Experiments\CIBuildDef\bin). I'm accustomed to a new folder being created by the build every time. I must be missing something in the build definition settings. Am I getting this error because I'm not changing the version number of the package yet? I cannot seem to delete the nupkg that was originally dropped in the Builds directory, even after deleting it from the feed.
How do put my NuGet package onto the feed with TFS?
How do run my Octopus Deploy steps from TFS?
Am I asking the right questions?
Thanks for any input you can provide.
Could you ping your octopus server from tfs build server? And could you telnet to 8081 port from your tfs build server? If you could, you should rebuild the project not build for the same repository. If the new nuget version is not higher than 1.0.0.0 octopack could fail. You must increment the nuget version from your tfs build template. The following commands must be work for you. This commands are for msdeploy deployment with powershell. If you want to use msdeploy you must install it to tentacles. I am using it for web project deployment.
Command line arguments:
/t:Rebuild /p:AutoParameterizationWebConfigConnectionStrings=False
/p:DebugSymbols=false /p:DebugType=None /p:IsAutoBuild=True
/p:CreatePackageOnPublish=true /p:Configuration=Release;DeployOnBuild=True;PackageLocation=".\obj\Release\Myproject.zip";PackageAsSingleFile=True /p:RunOctoPack=true
/p:OctoPackPackageVersion=%VERSION%-dev
/p:OctoPackPublishPackageToHttp=http://octopus.yourdomain.com/nuget/packages /p:OctoPackPublishApiKey=API-xxxxxxxxxxxxx
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.