We've been using TeamCity for some time without issues. We went a few weeks without doing builds and our server team installed .NET 4.5.1 on the server. Now all of our builds are breaking.
Here is the command line being ran (edited for privacy):
C:\Windows\Microsoft.NET\Framework64\v4.0.30319>msbuild "C:\programs\TeamCity\bu
ildAgent\work\<path to proj file>.csproj" /t:Package /P:Configuration=Test
Which results in this error:
The target "Package" does not exist in the project.
Lots of results talk about this being a missing visual studio folder named "web" or not having web deploy installed. That is not the case here. Those solutions are not working.
Related
Project Setup : Mixed framework solution
.Net Framework 4.6.2 projects in solution : 15
.Net Standard 2.0 projects in solution - 1
Development Machine
Visual Studio 2017(15.7.4) : Builds without any errors
Build Server
TeamCity Version 2017.1.3
Build Steps
Nuget Restore(3.4.4)
dotnet Restore
MSBuild( Build Tools 2017), Tools Version 15.0
Build fails with following error in the .net standard 2.0 project : [ResolvePackageAssets] C:\Program Files\dotnet\sdk\2.1.301\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(198, 5): Package System.Security.Cryptography.ProtectedData, version 4.4.0 was not found. It might have been deleted since NuGet restore. Otherwise, NuGet restore might have only partially completed, which might have been due to maximum path length restrictions.
What's interesting is I can't find reference or use of System.Security.Cryptography.ProtectedData anywhere in the project. Any help is greatly appreciated.
P.S - Can't use dotnet build, as the solution needs building of licenses.licx files, and the component which builds it (Microsoft.Build.Tasks.LC) is not ported to .Net Core. The suggestion from various posts was to use MsBuild.exe
Our .net core 2.1 solution compiles fine on our local development machines with .net core sdk 2.1.301. Appveyor used to compile the solution in its CI pipeline when there was no database projects defined. Once such a project added, Appveyor started failing in building the solution with the error message below. Any clues how to address this issue?
C:\projects\comingsoon\ComsingSoonDatabase\ComsingSoonDatabase.sqlproj(57,3):
error MSB4019: The imported project "C:\Program
Files\dotnet\sdk\2.1.300\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
The database project can only be built using the full framework MSBuild tools included in visual studio.
Depending on how you set up appveyor, you need to change your definition to use msbuild.exe instead of dotnet commands.
I've updated my app from DNX, ASP.NET 5 RC1 to ASP.NET Core 1.0 RC2.
Locally it builds and runs fine.
On the build server, I don't have Visual Studio installed, and the build fails with:
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
I did install the: .NET Core SDK for Windows.
Trying to install the VS 2015 tooling preview fails with:
What would be the correct setup to build .NET Core 1.0 RC2 app on the build server without having to install Visual Studio 2015?
Note: The build box (TeamCity 9) builds/runs tests fine for .NET 4.5 and DNX.
https://learn.microsoft.com/en-us/dotnet/articles/core/windows-prerequisites#issues
Issues
You may be blocked from installing the .NET Core Tooling Preview 2 for Visual Studio 2015 installer due to a temporary bug. To workaround it, run the installer from the commandline with the SKIP_VSU_CHECK=1 argument, as you see in the example below.
DotNetCore.1.0.0-VS2015Tools.Preview2.exe SKIP_VSU_CHECK=1
I'm able to build the solution now. Still can't publish though.
I just copied all the new MSBuild stuff to the build server. I copied:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\
From my local computer to the build server. That includes the new DotNet sub-folder, which contains:
Microsoft.DotNet.Common.targets
Microsoft.DotNet.Extensions.targets
Microsoft.DotNet.props
Microsoft.DotNet.Publishing.targets
Microsoft.DotNet.targets
Microsoft.DotNet.Tasks.dll
Microsoft.VisualStudio.ProjectSystem.DotNet.Runtime.dll
Newtonsoft.Json.dll
I can build the Solution (without the publish arguments) it fails when I try:
MSBuild.exe Solution.sln /p:DeployOnBuild=true /p:publishprofile=local
You can build and test you project via the command line - so there is no need to have Visual Studio installed. By using build steps of type "Command Line" you can run: dotnet restore, dotnet build, dotnet test
Here you can find some description how to run that as a build on TFS. It is written for the hosted TFS but works on-premise as well (and is not only meant for azure as the name of the document might imply):
https://www.visualstudio.com/en-us/docs/build/apps/aspnet/aspnetcore-to-azure
For the pubsishing I have used msdeploy with RC1 but have not yet migrated my deployment build. I might document it here when this is done within the next days.
So without Visual Studio or Web Deploy, my TeamCity build is comprised of 4 builds steps:
dotnet restore
dotnet build
dotnet test
dotnet publish -c Release
I run dotnet test on all projects with a basic for loop.
We have with success been updating our development web site at a daily basis using msdeploy from TFS2010.
This was working fine until we upgraded to VS2012, our application from .NET Framework 4.0 to 4.5 and ASP.NET MVC from 3.0 to 4.0. It look like all is well and assemblies deployed but nothing has actually been deployed.
I have been looking into this for two days now and can't figure out why this is happening and now I am running out of ideas.
Below is part of my build script in the way it has been working before the upgrade.
<MSBuild
Projects="$(SolutionRoot)\My.Web\My.Web.csproj"
Properties="MvcBuildViews=False;AllowUntrustedCertificate=True;AuthType=Basic;Configuration=Dev;CreatePackageOnPublish=True;DeployIisAppPath=dev.myweb;DeployOnBuild=True;DeployTarget=MsDeployPublish;MSDeployPublishMethod=WMSvc;MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd;UserName=UserName;Password=Password;UseMsdeployExe=True"
ContinueOnError="False"
/>
When the upgrade was initiated and my problem discovered we were using Web Deploy 2.0 but now we have upgraded to Web Deploy 3.0. I have also made sure we are building with ToolsVersion="4.0".
UPDATE --
msbuild.exe /p:AllowUntrustedCertificate=True
/p:AuthType=Basic
/p:Configuration=Dev
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath=dev.myweb
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:MSDeployPublishMethod=WMSvc
/p:MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd
/p:UserName=UserName
/p:Password=Password
/p:UseMsdeployExe=True
E:\Builds\1\WhatEver\Daily_Build\Sources\My.Web\My.Web.csproj
Now I also tried to run the above msbuild command from our TFS and no response which frustrates me completely. Nothing in the event log of TFS, nothing in log file no matter verbosity... Any ideas?
It does work using msdeploy directy like below;
<Exec Command=""C:\Program Files\IIS\Microsoft Web Deploy V3\MSDeploy.exe" -verb:sync -source:contentPath="E:\Builds\1\WhatEver\Daily_Build\Sources\My.Web\My.Web.csproj" -dest:contentPath="E:\dev.my.web",computername=https://10.xxx.xxx.xxx:8172/MsDeploy.axd,username=UserName,password=Password,authtype=Basic -allowUntrusted=True"
ContinueOnError="false" />
--
UPDATE 2 --
It appears Microsoft added a check for what type of projects that are publishable projects and our web application are not, since the Output Type is Class Library. This has been valid with v4.0 but apparently not for v4.5.
Anyone have an idea of what to do make it work again? Do I need to change the project type? Create publishing package up front and then deploy that? Or what?
--
Anyone else that has had the same problem? Have you found a solution to share?
Could there be an issue with version of MSBuild?
Here is what I would recommend. In VS2012 we have made it easy to automate publishing your web projects using the publish profiles which are created by the publish dialog. In your case create a new MSDeploy profile. When you create that profile we will save the settings into a file under Properties\PublishProfiles (or My Project\PublishProfiles for VB). The extension of this file will be .pubxml. Those files are actually MSBuild files, which you can customize if needed. You can continue to use the publish dialog as well. The password will be stored in a .user file and encrypted such that only you can decrypt it.
After you have created that profile you can publish with the command below if you are building the .sln file.
msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password>
If you are building the .csproj/.vbproj then you need to tweak this a bit in the following way
msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password> /p:VisualStudioVersion=11.0
More on why VisualStudioVersion is required at http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx.
Once you do this you will be able to build+publish just like you did previously. FYI we have shipped all these new web publish features for VS2010 in the Azure SDK https://www.windowsazure.com/en-us/develop/net/#.
Also in your question I noticed that you are specifying some custom properties, like MvcBuildViews. You can now place those properties directly inside the publish profile (the .pubxml file) if you want. Of course you can still pass them in on the command line if that makes more sense for your scenario.
More info on this at http://sedodream.com/2012/06/15/VisualStudio2010WebPublishUpdates.aspx.
If you take a look at the approach that we had for developers to automate publishing it was to specify properties and targets to be executed during the build. The problem with this approach is that this limits our ability to enhance the web publish experience. In the new release we have introduced an abstraction, the publish profile, which allows us to change the underlying targets of the web publish pipeline and your automation scripts will continue to run. Hopefully from this point forward you will not have to re-visit this issue.
I had much the same problem today. I too was trying to get a .NET 4.5 web application automatically deployed using a machine that did not have Visual Studio 2012 installed on it. There were a couple of minor differences in my situation, however: I was using TeamCity instead of TFS, and our solution was created with .NET 4.5 as opposed to being one that had been upgraded from .NET 4.0.
Nonetheless, I did have the same problem described. I'd use MSBuild to build the web app and deploy it to IIS, in much the same way. This approach worked fine on my dev machine. However, when I ran MSBuild on the CI server, it quite happily built the web app, but it stopped after that: no errors, no warnings, nothing, just a message that the build was successful. There wasn't the slightest hint of an attempt at deploying the app to IIS.
It seems MSBuild was missing the relevant targets to perform the web deployment.
The fix was to copy the folder C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web from my dev machine to the CI server, copying it to the same place on the CI server as it was on my machine.
Once I did that, MSBuild then grumbled about needing Web Deploy 3.0, but that was fixed easily enough. After installing that on the CI server too, MSBuild quite happily deployed the web app.
To extend Luke Woodward's answer:
I, too, found that deploying C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ from my local machine to the build server was the fix.
However, the real fix is to install the Microsoft Web Developer Tools as part of the VS 2012 installation, which will create this folder, among other things. This addresses Ieppie's licensing objection.
I tested this by...
Deleting C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\
Running the VS 2012 installer and adding MS Web Dev tools.
Verifying that, after the install, C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ was back.
I have a Build server which has TFS 2010 Build Service installed. I have 2 Build Agents and 1 Controllers configured. One of our projects have been converted to Visual Studio 2012.
I found out that .NET framework 4.5 comes with new version of MSBuild which is version 4.5.
I installed .NET framework 4.5 on the Build Server because prior to installing it every time the project was built I kept getting the following error:
"Solution is of version '12.00' which is not currently supported".
After installing .NET 4.5, I still run into the same issue.
How could I go about resolving this?
Do I have to configure the Build Agent to use the new MSBuild 4.5 in order to build this particular project or do I set something in the projects solution file itself? If so how?
I would really appreciate if somebody could assist me with this please?
Try install vs2012 on the build server, while i don't believe it's strictly needed it's the easiest way to get all the requirements installed.
We have installed VS2012 on the build agent. Interestingly when I RDC to the build agent and then run msbuild from the command line everything works fine. So the issue looks like it happens before we even get to MSBuild.