I have a Teamy City Build Server and wanted to migrate my solution piece by piece to Package Reference. Unfortunately it seems that it doesn't find the references / packages for those project I already moved or reacreated with package reference. The packages are restored correctly as I see them in the global .nuget\packages folder. Also I can build locally without any issues.
Funny enough, I have some other smaller projects which do work correctly with package reference on teamcity.
TeamCity Version: 2019.2
NuGet: 5.4
I also tried to add a .NET CLI Task with a restore command, but that didn't change anything aswell.
NuGet Installer Step:
dotnet restore step:
In the end I create a new pipeline and reconfigured all the steps from scratch instead of copy an existing pipline and now it works. seems there was some issue somewhere attached to those existing pipelines.
After an entire day of trying to fix this problem I finally found the cause.
In the parameters of the build configuration in TeamCity there was a parameter called "system.VisualStudioVersion" with its value set to "11.0". I changed the value to "16.0", and this fixed the problem for me.
This might explain the solution of NPadrutt, assuming he had the variable set in that particular build configuration. Recreating his build configuration would then result in a new build configuration without the bad parameter, fixing the problem for him. But in my situation the parameter was inherited from the root project, so recreating the build configuration wouldn't have fixed it for me.
Related
I'm pretty new to OctopusDeploy and am trying to set up a process to deploy our artifact to multiple Windows Servers.
As of right now it is deploying the package to the default working directory of C:\Octopus\Applications...... but I need it to be deployed to a different path.
I have defined a Custom Install Directory in the process editor, however this seems to be overlooked during the deployment, and the package just goes to the default directory.
I have tried substituting the path with a variable, but that didn't fix it. There are no errors or warnings in the deployment logs.
Can anyone help?
Sounds like you're taking the right steps to change your custom installation directory on your deployment.
One thing to check is that you've created a new release since updating your step configuration. Because releases in Octopus snapshot the deployment process, any updates you make won't show up in your deployments until you've created a new release.
We have a project with a dependency on a custom NuGet feed (also hosted in VSTS).
I'm trying to put together a new phase to generate code coverage reports, as in this blog post. My new phase looks like this:
And is made up of the following steps:
.NET Core Tool Installer - use SDK 2.0.0
dotnet restore with my custom feed selected in the "Use packages from this VSTS/TFS feed" drop-down
dotnet test with the relevant arguments to collect code coverage
A custom step using ReportGenerator
A step to publish the results
The problem is that dotnet test insists on trying to restore the packages itself. As I can't find a way to tell it to use a custom feed, it fails when trying to restore these packages:
D:\a\1\s\MyProject\MyProject.csproj : error NU1101: Unable to find package My.Package. No packages exist with this id in source(s): Microsoft Visual Studio Offline Packages, nuget.org
My main build process works fine and is able to restore the package from the custom feed. The difference is that uses the Visual Studio (i.e. not dotnet) versions of the commands:
What's the right way to handle this?
Do I need to find some way to tell dotnet test about my custom feed?
Or (given that I'm running restore immediately prior) do I need to persuade it to skip the restore altogether?
In case anyone else has this problem, I'm sorry to say our route to resolution was to merge the two repos, effectively negating the need to use the private Nuget feed.
We did have a bit of back and forth with a rep from MS, but didn't get to the bottom of it.
I had similar problem with dotnet test and custom nuget feed.
The solution was using two steps:
dotnet restore --source (my feed sources)
dotnet test --no-restore
See Implicit restore
What's the right way to handle this?
In step dotnet restore, make sure field Path to project(s) specifies all relevant projects. (It's easy to forget a project and that would result in the behavior you experience.) For instance, you can specify the value **/*.csproj. If you do this correctly, other steps such as dotnet test should not even try to restore packages since they have already been restored.
Do I need to find some way to tell dotnet test about my custom feed?
No (assuming step dotnet restore has already restored the packages)
Or (given that I'm running restore immediately prior) do I need to persuade it to skip the restore altogether?
No. It will automatically skip restoring (assuming step dotnet restore has already restored the packages)
I had the same error on a self hosted build agent. Once I changed the star syntax (get latest version) in the project file to a fixed version the problem went away. I am bit sad that I cant use the version syntax.
We deploy ASP.NET Web Api to a web server using MSDeploy. It is launched from TeamCity, which has an MSBuild step that build code and deploys it. MsBuild is run on our web API project only (lets call it WA), not on the whole solution. I don't know if it's relevant. I think it's not - see why lower.
Our API generates Swagger documentation. Problem is - Swagger can't find the XML documentation for one of the projects (lets call it B) that WA depends on.
When I build solution on my development machine - Swagger works fine without errors. Problem only appears when we deploy from TeamCity to our test environment.
I investigated and found that missing file is generated during build, but MsDeploy won't package and bring it over. That's why I think MsBuild on project vs solution is not an issue here.
First thing I did was add <DocumentationFile> node for every configuration of projects B and WA. That didn't help much.
Here are MsBuild parameters we use on TeamCity:
/property:Platform=AnyCPU
/property:DeployOnBuild=True /property:DeployTarget=MSDeployPublish /property:CreatePackageOnPublish=True /property:AllowUntrustedCertificate=True /property:MSDeployPublishMethod=WMSvc /property:SkipExtraFilesOnServer=False
/property:DeployIisAppPath=OurApiName. They are fairly standard.
We also provide some other parameters through system properties - Configuration, UserName, Password, MsDeployServiceUrl.
I did try this solution, but the problem is still there.
If anyone else hit this - I solved the problem by modifying my .csproj file according to this article.
Couldn't get it working at first, but then I tried all the path combinations I could think of and one of those worked. Be careful with leading slashes
I'm just looking at streamlining the nuget packages that are coming out of my build system and I'm stuck on how to only package the files that are required.
I have several configurations sharing a Root VCS checkout. I have a configuration that runs a debug build with unit tests. I also have a release configuration that does a release build, this configuration then also uses the TeamCity OctoPack plugin to create the nuget packages.
What I want to achieve is the building of nuget packages that don't contain the *.pdb and *.xml documentation files as these aren't required for the release deployment.
I've looked through this page on the OD site:
http://docs.octopusdeploy.com/display/OD/Using+OctoPack
And according to this page OctoPack should only package up the required files by default. I'm not entirely clear on how or what needs to be done to get around this problem as it doesn't appear to be working as described.
It seems that one solution would be to provide a nuspec file for the projects I'm looking to deply but I'm also wondering if there is something I'm missing before I head off down that route.
I also have some MEF plugins that are copied in post build events and these aren't included in the nuget packages when in fact they are needed for the application to run. I think I need to get explicit with a nuspec file but would like to confirm this.
What is the simplest way of achieving what I need?
Assuming you're running the later versions of OctoPack, in your release build you can set a system parameter system.DebugType = None which will get passed to the OctoPack build scripts and prevent the PDB's being created.
This simply overrides the setting defined in your csproj msbuild file (assuming C#), so you can use it wherever you want to prevent PDB's being created at the build configuration level (not just OctoPack). I generally prefer this approach as it prevents side-effects in your build from changes by developers in the project file.
As for the xml files, I haven't actually tried this, but you can try a similar approach and create a system parameter system.DocumentationFile = "" to blank out the output.
If you really want to make sure that the files have been removed there are a couple of ways you can do this. Modify your deployment process to:
Execute your own custom PowerShell script in that removes the files
Include a script module from the Octopus Library to the same. Check out the File System - Clean Directory from the Octopus Library
We've been using TeamCity as a NuGet server with great success. Last week I migrated TeamCity to a new server machine. The database remained where it was on an external server. I copied the artifacts folder to the new server and I can see them all listed on the project configuration page. However, the old packages are not showing up in the NuGet package feed. What else do I need to do to get the new TeamCity server to list those old packages in the feed?
Other projects that depend on older versions of these packages are currently broken because they can't be found.
New builds of those NuGet packages are showing up in the feed, but I also need all the old ones.
thanks demis. you put me on the right path to resolving this for me.
to make the answer here a little more complete and formal:
overwriting the following files:
provider-nuget.data
provider-nuget.index
in \system\caches\buildsMetadata
with the same files from the old build server worked for me (before creating new builds - not sure you'd be able to get a merge done after the fact).
I don't remember now exactly what I did to fix this, but it had something to do with the files inside this folder on the server running TeamCity: C:\ProgramData\JetBrains\TeamCity\system\caches\buildsMetadata
Did you move the old artifacts from older builds as well?