I've been pouring over my set up for what feels like most of the day and I cannot figure out what I'm doing wrong.
I have 3 build configurations running on a single agent on my dev box. Checking out code from SVN.
I've got OctPack installed to create a couple of packages for deployment. In addition to this I've created a nuspec file to use in a NuGet Pack step. All of these bits work fine when testing.
The problem is that the nuspec file packages up some sql script files for deployment. Nothing fancy.
The problem is these sql files are disappearing from disk in the work folder. I get:
Cannot start build runner: Failed to find files to create packages matching: [src\database\SqlScriptsPackage.nuspec] under H:\TeamCity-Build\work\a1dbf81458fbab0a.
The entire database directory is empty despite all the contents being in SVN.
I've tried everything I can think of, including a forcing a clean checkout.
All the projects are using the same VCS Root setup to checkout "Automatically on server".
What could be ditching all these files?
Disable the [] Clean output directory checkbox on the NuGet Pack step.
I had this issue where I set the target directory for the Nuget pack step to be the same folder as the .csproj file I was building from.
With the tickbox ticked, it wiped the entire directory immediatly after checking it out.
I had a similar error when running on TeamCity:
Failed to find files to create packages matching: [myProject/myProject.nuspec]
under {C:\TeamCity\work\XXXXXXXXXX}
The key for us was that reading this message you could interpret it as it cannot find the files to go in the nuget package.
However, the issue was that it cannot find the .nuspec file.
So this then helped us look at the TeamCity working directory and what we were missing to get to the 'myProject' .nuspec path above.
Another thing to check is that you have the Octopack nuget package installed in your Visual Studio project. I forgot to do this with one of my projects and received the "Failed to find files to create packages matching" error. More information is available here:
http://help.octopusdeploy.com/discussions/questions/2304-teamcity-804-not-creating-nuget-packages
Related
I have a .net website written some years ago which causes an error when being built in TeamCity. when teamcity gets to the second build step, MSBuild of the site's csproj file, i get this error when it tries to run package restore:
"The '…' package requires NuGet client version '2.12' or above, but the current NuGet version is '2.8.60318.667'"
The reason for this is that this solution includes the nuget.exe file in its directory which is of version 2.8.60318.667. Other projects/websites that i work on do not have the nuget.exe file in them and seem to be building in teamcity okay.
I need to either (1) update the solution so that i can remove the nuget.exe file, or (2) use the latest version, which should hopefully fix the teamcity issue.
When i replace my nuget.exe file with the latest from nuget i get an error message on build:
"1>D:\Sites\testSite.nuget\NuGet.targets(100,9): error : Could not find a part of the path 'D:\Sites\testSite\ \packages\System.Security.AccessControl.4.4.0'."
I think there is a space somewhere in a configuration file between the solution directory and the package location but i'm not sure where to look. Can anyone help?
I have tried deleting the .nuget folder from my solution but i get errors when i build. Can anyone help me reconfigure my solution to work without the specific, local version of nuget?
If anyone can help in any way i'd really appreciate it, i'm reaching the limit of my understanding of visual studio and .net.
thanks
Sam
You can install multiple versions of Nuget tool in TeamCity and set any one as default
i.e v4.4 as default.
For this follow the TeamCity doc link : TeamCity Doc
Now for specific build step if you want to use lower version of nuget you can choose different version of nuget installer/restore as shown in attached image
The issue I had when replacing the nuget.exe file was due to the version of the file I downloaded. I took an older version (4.6.4) and I did not get the issue with the space in the path to the packages when building the solution.
There were other errors but i have resolved them now.
I am using mspec (machine specification) unit test framework for .NET project.
I used nuget to get all required packages.
There is a specific package, that is not part of the code. It is the "Console" application for the mspec that I used to run my unit tests from outside VS, from the command line.
(It is located here):
When I use Nuget to install it, Nuget doesn't add it to the normal "packages.config" file inside of the Test project.
It is adding it to a "packages.config" folder that exists in ".nuget" folder.
But when my colleague open the project and build, his VS doesn't get that package.
How to change that, to force VS to get the package automatically?
Nuget doesn't add it to the normal "packages.config" file inside of the Test project. It is adding it to a "packages.config" folder that exists in ".nuget" folder.
That is because you are using NuGet 2.7 or later and have a solution that is still configured by old package restore method "MSBuild-integrated restore". This will cause builds to fail with an error stating that you have not given consent to restore packages. Visual Studio will skip automatic package restore.
How to change that, to force VS to get the package automatically?
To resolve this question, you can follow below steps:
Close Visual Studio to avoid file potential file locks and conflicts.
If using TFS: a. Remove nuget.exe and nuget.targets from the solution's .nuget folder and remove those files from the solution workspace. a. Retain nuget.config with the disableSourceControlIntegration setting as explained in Omitting packages with Team Foundation Version Control.
If not using TFS: a. Remove the .nuget folder from the solution and the solution workspace.
Edit each project file in the solution, remove the <RestorePackages> element, and remove any references to the nuget.targets file. For more detail information, you can refer to Migrating to automatic restore.
I updated to VS2015 this week and along with that updated all NuGet packages in my website solution.
The site builds and run fine locally, however when doing my gated check in to my build server, I get the following when the build fails
As you can see the packages are complaining about the NuGet version, but I'm unsure how to update the NuGet version on the build server. I do have admin privileges to the server, but following the guild described at: http://blog.stangroome.com/2014/02/04/update-nuget-exe-version-used-by-team-build-2013-package-restore/ did not help. For one, my folder was actually C:\Program Files\Microsoft Team Foundation Server 11.0\Tools unlike the C:\Program Files\Microsoft Team Foundation Server 12.0\Tools described in the guide, but additionally I did not have a NuGet.exe within the folder.
I've done a full hard drive search of NuGet.exe, but could not locate it in any directories aside from the directories that are directly related to project source code (.nuget\NuGet.exe).
I have opened visual studio on the server and updated the NuGet version within "Extension and Updates" hoping that would fix the issue, unfortunately it did not.
Any ideas on how to fix the issue/errors presented in the screenshot?
The problem is that you're using the old-style, deprecated-since-NuGet 2.7-style "package restore" that's based on modifying your CSProj files to include references to a NuGet.targets file and a copy of NuGet.exe that gets put into a .nuget folder and ends up source controlled.
Basically, the version of nuget.exe that's on the build server is irrelevant right now -- your CSProj files are pointing to the file in your .nuget folder.
TFS 2013 and beyond has support for automatic package restore without using the NuGet.targets method. You can migrate off of it pretty easily: https://docs.nuget.org/consume/package-restore/migrating-to-automatic-package-restore
My issue is "When I build a project on my build server, it does not get the correct version. But when I build it locally the project locally it does get the correct version"
How do I know this? ...On the build server when I open the file, the contents are not what they should be, as they are in TFS.
I am using Visual Studio 2013 and WIX 3.8. On my build servers I have wix 3.8.
I have a WIX installer (INSTALLER XYZ) which references project A.
Project A has a configuration.config file inside it. The configuration.config file is essential for the MSI to work. When I build the "installer XYZ" locally and install it everything works fine.
When I run a build (on the build server) it builds "installer XYZ" and produces a .msi file. When I install the .msi file I get an error. The install fails.
After investigating and I have found out that when I build on the build server, the "installer XYZ" which references Project A configuration.config file is using an older version of this file and not the latest version. I don't understand why this is happening.
If I use the .msi which was built locally, it installs fine but when I use the .msi which was built on the build server, it does not install.
Let me explain a few things that I have tried...
The msi's are exactly the same except for this configuration.config file. I have used the tools LessMsi and Orca to examine the .msi's.
When I build the project on the build server, I have checked the configuration.config file and it is different the one in Project A
I have got the latest from TFS before building. I have got specific and overwritten all the files from TFS before building.
I have expanded project A and right clicked on configuration.config file and selected properties. The property "COPY TO OUTPUT DIRECTORY" is set to COPY ALWAYS".
My WIX installer is harvesting the files correctly. I have recreated my .WXS file and referenced project A correctly using Source="$(var.Connectors.AgentService.TargetDir)"
On my build server I have deleted all workspaces.
I have deleted all work spaces that my build service account created.
My build definition "Clean Workspace" is set to "All"
I have restarted my computer and the build server
To conclude, I know what the issue is but I'm not sure what's causing it... Can anybody advise?
Update 22.05.2014
So I've investigated further,
I have another project in the same solution called Project.B
Project.B also has a configuration.config file.
What seems to be happening is that the configuration.config file from Project B is being built. I tested this by changing the contents of project.B configuration.config file and rebuilding it. However, my WIX installer references project A configuration.config file.
It seems that the build process is getting confused between the two projects in the same solution.
Does anybody know why this could be happening?
In TFS build, all files are copied into one bin folder. However, Visual Studio has "bin folder per project" structure.
This would explain why your configuration.config is overridden by projectB. They are all copied into same folder.
You can split the folder structure again, by adding this property to your build definition:
Notice the flag /p:GenerateProjectSpecificOutputFolder=true
When I try to pack my MVC project (NuGet.exe pack) I get:
NuGet.exe : Access to the path '...' is denied.
This happens to be the case for all files in the content and script folder of my MVC solution. If I remove the readonly flag on all these files NuGet.exe is able to create the NuGet package.
Why do I have to remove the readonly flag? Is there another way?
I'm using TFS which specify the readonly flag on all files under source control.
I am running:
NuGet Version: 1.7.30402.9028
Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel
I'm using the NuGet.exe that you get when you install the NuGet package NuGet.CommandLine which is located at http://nuget.org/packages/NuGet.CommandLine.
Apparently, you need to set ReadOnly=false for the files it accesses
Try running it as administrator.
I ran into this with nuget restore after doing a git clean -fd with VisualStudio open: the packages/ directory was marked for deletion, and while several files were deleted, the packages/ folder itself was not as VisualStudio had the .nupkg files open.
Once I closed VisualStudio and re-ran git clean, it removed the packages/ directory and then nuget was able to restore everthing correctly.
In my case something happened when switching branch in git. Everyone lost execute permissions for Nuget.exe.
This blog post helped me: http://mannysiddiqui.wordpress.com/2013/05/11/nuget-access-is-denied-command-existed-with-code-5/
I was running into a similar problem. I attempted to restart Visual Studio, Run as Administrator (Which I always do), Set the folder attributes to ensure the 'Read-Only' flag was off. Regardless, whatever I did, I still encountered the error "access to the path is denied" when updating my Nu-Get packages.
I was able to fix the issue by updating packages one-by-one. Choosing instead to go through each dependency and updating it. Once the dependency was updated I would choose another, sometimes the same error resulted in which case I would choose another until all my packages were successfully updated.
It appears in my case the Nu-Get packages had to be updated in a particular order.
Hope this helps someone out there
I had this problem and it turned out windows had an update waiting for the next restart. Cleared with no problem after restarting and waiting for the update.
My collegue just got this error, during all "worked on my machine". After some research I found out that the *.nuspec file for some reason wasn't added to the version control.
In order to Restore nuget packages, remove read only permissions from the folder level (for windows). Clean the solution and Build. It will works
In my case it was *.gitattributes in the git repo root recently modified (incorrectly), so git started to checkout nuget.exe on the build server and converted all LF to CRLF inside, making it non-executable.
Run your Visual Studio with administrator rights.