I have a solution containing multiple .Net Core projects, some of which are dependent on other projects in the same solution. The whole solution is hosted in a Git repository of an on-premises TFS server.
I want to set up an automated build process on the TFS server. For lack of better knowledge, I use the Visual Studio build template and leave all the settings on their defaults. When I run the build process, it fails on the "Build solution" step with the error message
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets(262,5): error : Project MyProject does not have a lock file.
Please run "dotnet restore" to generate a new lock file. [C:\TFSBuildAgent_work\6\s\MyProject\MyProject.xproj]
So I go ahead and create a PowerShell script with the content dotnet restore that I run before "Build solution" but after "Nuget restore". This also fails, this time on step "Dotnet restore" with the error message
Errors in C:\TFSBuildAgent_work\6\s\MyProject\project.json
Unable to resolve 'ProjectDependency (>= 1.0.0)' for '.NETFramework,Version=v4.6.1'.
When I run dotnet restore on my local machine, it completes without any issues.
Any help or hints are greatly appreciated!
I helped myself now in packaging the project dependency and uploading it to my inhouse package server. dotnet restore will then pull it from the server and build the whole project. Not the nicest way, but at least it's working.
Related
We recently moved up to TFS 2017 and I'm trying to get our existing builds transitioned from XAML based ones to the new build system. This is all behind the corporate firewall.
My test project (dotNet Core) was failing with the error...
Assets file '<snip>project.assets.json' not found. Run a NuGet package restore to generate this file.
...so I added a Nuget Restore step to the build. This resulted in the following error appearing in the build log...
<snip>
Starting: NuGet restore
**************************************************************************
==========================================================================
Task : NuGet Restore
Description : Restores NuGet packages in preparation for a Visual Studio
Build step.
Version : 1.0.1
Author : Microsoft Corporation
Help : [More Information](https://go.microsoft.com/fwlink/?
LinkID=613747)
==========================================================================
C:\Windows\system32\chcp.com 65001
Active code page: 65001
...waits here for 30 seconds...
connect ETIMEDOUT 117.18.232.200:443
**************************************************************************
Finishing: NuGet restore
<snip>
However, checking with both Fiddler and the network people, there is no (relevant) network activity from the box at the point that it waits about 30 seconds, at the point shown.
Clearly the Nuget Restore step is attempting to access the internet but is unable to due to it being unable to access the proxy (we had a similar issue initially setting up the build server) rather than it being blocked which would show in the network logs.
If I remote to the build server and login using the same credentials as the build service I can successfully use VS to build the test project on the box, but it is obviously using the IDE config file(s) to get to the proxy. I have configured the proxy in both the devenv.exe.config and the %appdata%\NuGet\NuGet.Config .
Can anyone suggest where else I can set it so that the Nuget Restore step can find it and use it, please?
Try the steps below on your build agent machine:
download the command line version of nuget
add it to the path env var
nuget.exe config -set http_proxy=http://proxy:port
nuget.exe config -set http_proxy.user=Domain\Username
nuget.exe config -set http_proxy.password=myPassword
Update:
The project.assets.json file maintains a project's dependency graph when using the PackageReference management format, which is used to make sure that all necessary packages are installed on the computer. Because this file is generated dynamically through package restore, it's typically not added to source control. As a result, this error occurs when building a project with a tool such as msbuild that does not automatically restore packages.
In this case, run msbuild /t:restore followed by msbuild, or use dotnet build (which restores packages automatically).
More details, please refer to the link below:
https://learn.microsoft.com/en-us/nuget/consume-packages/package-restore-troubleshooting
When I started writing this question, my problem was that after a successful VSTS Build, I wasn't able to see the files relating to my web application project for release. Only the files from certain other projects in the solution were present. However, I just came across this question, which has helped.
I can now see the compiled .dll files for my web application project, after altering the configuration of the Content setting in the Build - that is, the contents of the Bin folder under that project. But I can't see anywhere the other files I need to copy the built web application to my server - the views, the scripts, the css, etc.
I'm finding the power and flexibility of VSTS's Build and Release functionality very confusing as it's complete overkill for our requirements. Up until now, I've just right-clicked on the web app project in Visual Studio selected Publish and used the File System publish method. Easy. Now that I want to automate the building and deploying of the application, it's many times more complicated!
So, can anybody tell me how I can get the solution to build in VSTS in such a way that I can then use a Copy Files task in the Release Definition to copy the files to our web server (the server isn't visible to the Internet so I'm using a locally-hosted Agent)?
In vNext build, to publish your build artifacts with the Copy files or Publish build artifacts steps. Try to use the local path on the agent where any artifacts are copied to before being pushed to their destination. For example：
Add /p:DeployOnBuild=true
/p:OutDir="$(build.artifactstagingdirectory)\" arguments in Visual
Studio Build step；
Change "Path to Publish" of Publish Build Artifacts task to
$(build.artifactstagingdirectory)\_PublishedWebsites\ProjectName:
Details please check the screenshot of build step with this question: How do I get the the expected output from a TFS 2015 build (to match my XAML build)?
Base on your comments, you have published the web app from Visual Studio. Usually, this action will generate a publish profile under Project/Properties/PublishProfiles folder. The settings you used to publish the web app is stored in the profile. So you just need to make sure this publish profile is checked into source control. And then in the TFS build, add following MSBuild arguments:
/p:DeployOnBuild=true /p:PublishProfile="publishprofile.pubxml"
When I tried to use Jenkins as our CI environment to build ASP.NET MVC5 project, I set up to use MSBuild.exe to build project.
But when the cmd run into restore nuget packages, it stucked. The error message is as below:
WARNING: Unable to connect to the remote server
Unable to find version '3.4.1.9004' of package 'Antlr'.
Build step 'Execute Windows batch command' marked build as failure
But if I use windows command line to run the msbuild, it is working and could download the pkg from nuget.org. Error only happened when try to build in Jenkins. And my network is fine, but behind a company proxy/firewall, I am not sure what it is. And I have set to auto restore nuget package in VS2013.
Any idea is much more appreciated.
I finally found out the root cause, it is the Jenkins service has not enough access right. Open windows services and right click on the Jenkins service, in the security tab, change the default user to whom that has enough access right to the Internet.
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
I've just setup a TFS (2012) server and now I'm trying to build the complete code (written in .NET 4.0 in VS 2010) via the TFS Build server. But in my solutions I have also a WCF RIA project which contains linked files because they are used somewhere else also and there is no possibility to add a reference to a general .NET binary in WCF/Silverlight.
Everything builds without any problem on my development machine but when I check it all in, create a standard build definition and run that build definition I get the following problem. The linked files have usings (UsingNamespace for example) to other projects that are also build by us and build before the WCF/Silverlight but the following error pops up while building through TFS Build server:
The type or namespace 'UsingNamespace' could not be found (are you
missing a using directive or an assembly reference?)'
Is there any solution for this problem that I looked over?
EDIT 1
Just tried to set the Copy to Output Directory propertie of the linked files to Copy Always but this still gives me the same error as I was expecting. The problem is that the linked file is placed somewhere that it can use the usings but the WCF RIA service cannot access/find that using.
EDIT 2
Just tried out my local test TFS where I can do what I want and there I made a build definition with just the solutions needed to make that the project with the linked files builds. This worked without any problem. Then I tried the same on our TFS server with a new build definition that has the same solutions as on my test TFS and here it did not work. The only difference that I know for sure is that my test TFS is TFS 2012 Update 1 and that my production TFS does not have the update 1 yet. I'll try to install it next week.
EDIT 3
I've just updated our production TFS to Update 1 but it is still not working with my temporary build definition which only contains the projects that are needed to build the silverlight application with the linked files. The 2 workspaces are the same on both server and the projects to build are also the same.
You need to specify the workspace information in the Build Definition for the build to use. The workspaces are what the build process copies from source control to the build server. If you don't have everything in the build server's workspace, it can't build properly.
The Source Control Folder in the workspace tab is the location of the files you need from TFS. The Build Agent Folder is a relative path from the build server's pre-defined base location. You'll usually use $(SourceDir)\Folder to specify the "Folder" that your build process needs.
This sounds like an $(Outdir) problem. A build definition in TFS automatically overrides the Bin folder. All Binaries are redirected to the bin folder upon compile. Sounds to me that you are using a mixture of project references and file references. The file references are probably what is causing your build failures.
Example if you compile in the same build the following solutions
Solution1.sln (TFS Build Pass)
project1.csproj
project2.csproj (references project 1)
Solution2.sln (TFS Build Failure)
project3.csproj (references binary output of project 1)
Expectations from TFS out of the box without customizing your workflow is that this simple build will fail. The reason is that in your development box all projects produce output to one destination while in a tfs build your projects will build to $(Outdir).
Some Things to try
Simple (best practice in my view)
Create 1 solution and use project references instead of file references.
Complex
Build using MSBuild project files
Modify your windows workflow to not override the $(Outdir)
Copy the binaries after a build is complete.
Best practice on Automating Builds
Build from command line
Build from cmd a NON vs2010 command line.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe FullpathtoSolutionFile.sln
Cheers!
Apparently there was just missing the WCF RIA services V1.0 SP2 on the TFS server. If that was installed the problem was solved.