Hi
Having some troubles with an MsBuild action inside a FB7 script that continua runs. When I execute the script standalone using FB7, it all works fine - but continua running the same script shows the following:
Attachment unavailable
Hi
Having some troubles with an MsBuild action inside a FB7 script that continua runs. When I execute the script standalone using FB7, it all works fine - but continua running the same script shows the following:
Attachment unavailable
Hi Joel
You need to add a Nuget Install action to your script, and make sure nuget is installed on your Agent machine. Also, looks like it could be related to this :
http://stackoverflow.com/questions/9011889/nuget-package-restore-not-working
Thanks Vincent.
I’m not understanding why I need a NuGet install item, as Final Builder on the agent works perfectly without it when run outside of Continua. Is it a specific Continua script requirement?
Also, I have already applied the option referenced in the stack overflow post - you get a different error related to not having permission when you don’t have it set.
Joel
Hi Joel
The reason for the nuget install is that Continua builds each build in it’s own working folder, so the packages are not there in the folder when continua builds them. On your local machine with finalbuilder, it’s likely that the packages are there already and nuget doesn’t actually have to do anything.
Thanks Vincent, however I don't think that's the problem either. Here is the FB7 for the script, run on the agent, pointing at the Continua working folders for the above failed build:
Attachment unavailable
Hi Joel
I’ll do some testing here. I have used continua with nuget with no problems, but not with FB7 in the mix.
Hi Joel
Do you have Enable Package Restore enabled for the solution. If so then there should be a .nuget folder inside the solution folder. Is that checked into version control? I’m just trying to set up my test the same as yours.
Yes - I believe so. I have a .nuget folder with the NuGet.exe, NuGet.Config and NuGet.targets.
I just ran a test. Created a VS.net 2010 project, added a nuget package to it, and enabled package restore on the solution. Committed the project to an hg repo, including the solution and the .nuget folder (which gets created by the package restore feature, this folder also has the targets file). Created an FB7 project with an msbuild action, pointed at the csproj file, set configuration to release on the properties tab. Committed to source control.
In continua, created a new configuration, added an hg repo pointing at the repo created above, on the build stage, added an fb7 build runner action, pointed at $Source.nugettest$\BuildNugetTest.fbp7 , saved and ran it, worked first time.
Thanks for testing Vincent, that’s good news in some ways I guess Thanks for giving it a look!
Try turning on detailed output on the msbuild action, when I do that I see this in the output :
[code]Target "RestorePackages" in file "C:\ContinuaAgent\Ws\2510\Source\nugettest.nuget\nuget.targets" from project "C:\ContinuaAgent\Ws\2510\Source\nugettest\NuGetTest\NuGetTest.csproj":Task "Exec" skippedUsing "Exec" task from assembly "Microsoft.Build.Tasks.v4.0Task "ExecC:\ContinuaAgent\Ws\2510\Source\nugettest.nuget\nuget.exe" install "C:\ContinuaAgent\Ws\2510\Source\nugettest\NuGetTest\packages.config" -source "" -RequireConsent -solutionDir "C:\ContinuaAgent\Ws\2510\Source\nugettest\ Successfully installed 'Newtonsoft.Json 4.5.1'.Done executing task "Exec".Done building target "RestorePackages" in project "NuGetTest.csproj". [/code]
Thanks, that reference helps a lot. There are some obvious differences in my output. It’s using relative paths for NuGet as opposed to absolute paths (e.g. …nuget\nuget.exe), and mine isn’t using the -solutionDir argument, but rather the -o argument.
I’ll do some research into why mine is different. VS2012 (what I’m using) might be enough to account for the difference, but i’ll look at it all to determine if I can force some options in mine and see if that helps. I might also repeat the test using VS2010 and see if that goes through OK as you’ve observed. Thanks for the help, much appreciated!
I just tested with VS2012 (update 1) and got the same result, worked first time.
What version of nuget do you have installed?
Mine says : NuGet Version: 2.2.40207.9053
I have the same version.
I’ve reproduced my problem using a new solution (with package restore enabled), and a default MVC 4 Web Api project. Again, Final Builder runs the build, but Final Builder invoked by Continua does not. Unfortunately Continua is the only place I can reproduce the build error, so I’ve logged a bug related to Continua truncating the msbuild error lines; hopefully getting the full log message will help me figure out where to look next.
Short answer: declare a ‘EnableNuGetPackageRestore’ environment variable, and set it to ‘true’.
Well, this is embarrassing (as per usual). The ‘Allow NuGet to download missing packages during build’ option in Visual Studio is per user. The solution to our problem was to either run Visual Studio as the Continua user and enable the option (not easy in our case) or override it with the environment variable above, which is what we’ve now done.
Everything now works as expected. Thanks once again Vincent for support that goes above and beyond!
Hi Joel
Thanks for letting us know, I didn’t know the package restore option was a per user setting. I still think with a build environment like Continua, using the Nuget Install action and pointing it at the packages.config file for the solution is a better option, as it will not require and environment variable on the agent.
FWIW, we’re working on a nuget server module that will be part of Continua, so you can expect tighter nuget support within Continua in the future.
Could the nuget action in continua include the environment variables tab option, so developers don’t have to run VS 2012 as the continua agent role on every PC running Continua Agent. From what I can see with this issues is http://docs.nuget.org/docs/reference/command-line-reference nuget.exe allows for -config option which offers some promise for further Continua extensions.
While the documentation for Continua v1.0.0.x doesn’t allow for environment variable editing, could that be added to the list of future enhancements or validation checks for Nuget actions with continua in the future?
While the topic around Nuget package download security is not well discussed, I’ve added a change request to Nuget.exe to include an explicit command line option, so CI software doesn’t need to jump though these hoops. https://nuget.codeplex.com/workitem/3305