We have CCNET and msbuild creating our regular builds. I am trying to update our process so msbuild creates zipped deployment packages and msdeploy sends them out to the target IIS7 web servers. I was having trouble doing the end to end solution, so for testing I'm trying to just call msbuild from the command line for now. I execute this statement:
msbuild /target:Build;Package /P:Configuration=Staging;OutDir=D:\Builds\Viper.ProdSupport\MSDeployPkg\ /verbosity:diagnostic D:\builds\ViperPortal.ProdSupport\Code\Viper\Viper.UI.MVC\Viper.UI.MVC.csproj
and I get this error:
/temp/global.asax(1): error ASPPARSE: Could not load type 'Viper.UI.MVC.MvcApplication'. [D:\builds\ViperPortal.ProdSupport\Code\Viper\Viper.UI.MVC\Viper.UI.MVC.csproj]
Oh, and for our specs: .NET4, MVC3, IIS7/Win2k8 64bit for web server. Build server is Win2k8 as well, but I'm testing the scripts locally on a win 7 32bit box with ccnet and a full dev config mgmt environment setup locally.
Does anyone have any ideas why I'm getting this error? I read some messages complaining about the aspnet compiler or changing where your bin deploys assemblies to, but none of those seemed to really apply here. I am simply trying to call msbuild, which has been working all along til now. We have a custom msbuild script for our solution. I tried using both that and the mvc csproj file as the build configuration file. Please help! Thanks!
this happens if you've set to precompile views, i.e. you changed:
<MvcBuildViews>false</MvcBuildViews>
to
<MvcBuildViews>true</MvcBuildViews>
This is because MSBuild throws the output to different places than Visual Studio might, so you should change the folder on which the precompiling runs on from:
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(ProjectDir)" />
to:
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
Related
I have ASP.NET Core 2.2 app and I've been developing with VS2017, when I started using VS2019 the first thing that happened was the sln stopped building with error pointing to my .csproj files, for example
Severity Code Description Project File Line Suppression State
Error NETSDK1022 Duplicate 'Content' items were included. The .NET SDK includes 'Content' items from your project directory by default. You can either remove these items from your project file, or set the 'EnableDefaultContentItems' property to 'false' if you want to explicitly include them in your project file. For more information, see https://aka.ms/sdkimplicititems. The duplicate items were: 'plugin.json' ForkMeRibbon C:\Program Files\dotnet\sdk\3.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.DefaultItems.targets 316
The cause is that in my csprojs I have certain .json files I need to be included at build time, so I have these lines in my .csproj file like below which worked fine with VS2017, but VS2019 complains. After I deleted these lines and everything worked in VS2019.
<ItemGroup>
<Content Include="plugin.json" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
Then however after I checked my code into github, the build servers of Azure Pipeline, AppVeyor and Travis CI are not happy, they complain that my "plugin.json" file is not found. After some struggling, I was able to fix the build for AppVeyor by changing image: Visual Studio 2017 to image: Visual Studio 2019 in the yml file.
It seems like the build servers are configured with VS2017-ish configurations, unless you tell it to use VS2019 compatible configurations it will not copy over my json file thus causing errors. So far all Windows builds are fine, but the Linux and macOS builds on Azure Pipeline and Travis CI are not, for example here is a failed build on Travis, and message error MSB3030: Could not copy the file "bin/Debug/netcoreapp2.2/plugin.json" because it was not found.
Has anyone else run into this issue and how did you solve it?
I am trying to build, package and deploy a web application using Teamcity but for some reason Teamcity is ignoring the properties that I am passing to MsBuild.exe.
I have created a step in the build configuration to build, package and deploy teh application to the local server. Here are the properties:
/P:Configuration=Release
/P:DeployOnBuild=True
/P:DeployTarget=MSDeployPublish
/P:DeployIISAppPath=MyDeployedWebsitePath
/P:AllowUntrustedCertificate=True
/P:MSDeployPublishMethod=WMSvc
/P:CreatePackageOnPublish=True
/P:UserName=Administrator
/P:Password=******
/P:MsDeployServiceUrl=MyServerName
Passing them as command line parameters to MSBuild step or declaring them as System Properties in Parameters tabs doesn't seem to work. Teamcity builds the application but ignores the package and deployment steps!
If I execute MSBuild through command line on the same server (with the same params) the package and deployment works.
I am following the steps mentioned in Troy Hunt's series: https://www.troyhunt.com/you-deploying-it-wrong-teamcity_26/
I have read a lot of stack overflow questions and it seems to work seamlessly for others. I am not sure what's going wrong.
I would really appreciate any help.
Update - Build log
> Step 2/2: Build (MSBuild) (51s)
[18:32:48][Step 2/2] ##teamcity[buildStatisticValue key='buildStageDuration:buildStepRUNNER_18' value='0.0']
[18:32:48][Step 2/2] Starting: C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.MsBuildBootstrap.exe /workdir:C:\TeamCity\buildAgent\work\b12fe165603f4f19 /msbuildPath:C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
[18:32:48][Step 2/2] in directory: C:\TeamCity\buildAgent\work\b12fe165603f4f19
[18:32:56][Step 2/2] Targets were not defined in the build configuration.
[18:32:56][Step 2/2] MSBuild command line parameters contain "/property:" or "/p:". It is recommended to define System Property on Build Parameters instead.
[18:33:02][Step 2/2] EnsembleID.Web\EnsembleID.Web.csproj.teamcity: Build target: Build (37s)
[18:33:40][Step 2/2] Process exited with code 0
It turned out to be a version issue :/
I tried different options for MSBuild version - Microsoft .Net Framework 4.5, 4.0 etc.
Finally, Microsoft Build Tools 2015 option worked.
For the past week I have been banging my head on this and I lost track of what all different permutations I tried. I had installed all the different versions of framework tools and web deployment tools, I am not sure why the other options didn't work for me. So if someone is facing a similar problem, make sure to try out different MSBuild version.
I am trying to use MSDeploy to deploy an MVC project to the server using TeamCity. When I do this on my computer in powershell, using the following command:
msbuild.exe .\mvc.csproj /p:PublishProfile=DevServer /p:VisualStudioVersion=11.0
/p:DeployOnBuild=True /p:Password=MyPassword /p:AllowUntrustedCertificate=true
It builds the project and deploys it to the server (info defined in the DevServer publish profile) perfectly. The output shows an MSDeployPublish section at the end, in which I see text like Starting Web deployment task from source... and then with rows telling me what files are updated, etc.
When I run this on TeamCity, using an MSBuild Build step, on the same file, with the same parameters (from the same working directory) it builds the project but does not publish it. Instead it has the regular output from a build process (CoreCompile, _CopyFilesMarkedCopyLocal, GetCopyToOutputDirectoryItems, CopyFilesToOutputDirectory) but then does not actually go and publish anything.
What changes to I need to make to the setup in TeamCity to get it to publish deploy in the same way that it works using MSBuild from my computer?
(TeamCity 7.1, MSBuild 4.0, WebDeploy 3.0, Visual Studio 12, IIS 7. Related to my previous question)
We do our WebDeploys with a TeamCity MSBuild step configured as follows:
Build File Path: Server.csproj
Command Line Parameters:
/p:Configuration=%configuration%
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=https://%web.deploy.server%:8172/MsDeploy.axd
/p:DeployIisAppPath=%web.deploy.site%
/p:AllowUntrustedCertificate=True
/p:Username=
/p:AuthType=NTLM
We use integrated authentication; change as necessary to fit your scheme. The value of this, I think, is that it builds everything from scratch and doesn't rely on a pre-built package. From the gist you posted I noticed that you do some DB publishing, we don't use WebDeploy for that so I can't offer any guidance there. Hope this helps.
I use MSBuild.exe to package to zip, and MSdeploy.exe to deploy in separate steps.
To deploy the package.zip file on the command line:
"C:\Program Files\IIS\Microsoft Web Deploy V2\msdeploy.exe" -verb:sync
-source:package="C:\Build\MyAppName.Debug.zip"
-dest:auto,wmsvc=webservername,username=webdeploy,password=*******
-allowUntrusted=true
This command is also worth explaining in detail:
-verb:sync : makes the web site sync from the source to the destination
-source:package="C:\Build\MyAppName.Debug.zip" : source is an MSBuild zip file package
-dest:auto,wmsvc=webservername : use the settings in the package file to deploy to the server. The user account is an OS-level account with permission. The hostname is specified, but not the IIS web site name (which is previously specified in the MSBuild project file in the project properties).
You can modify parameters based on your configuration. I like it this way because with separate steps, its easier to debug problems.
Use TeamCity build step and the command line runner.
Update:
If you want an example of how to build the ZIP package using MSBuild, try something like this:
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
MyWebApp/MyWebApp/MyWebApp.csproj
/T:Package
/P:Configuration=Debug;PackageLocation="C:\Build\MyWebApp.Debug.zip"
This should work the same on your local PC as well as on the CI server.
Here are the config settings that finally worked for me:
/p:Configuration=CONFIG-NAME
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=http://SITE-URL/MsDeployAgentService
/p:username="USERNAME"
/p:password=PASSWORD
/p:AllowUntrustedCertificate=True
/P:CreatePackageOnPublish=True
/p:DeployIisAppPath=SITE-URL
/p:MSDeployPublishMethod=RemoteAgent
/p:IgnoreDeployManagedRuntimeVersion=True
I had exactly the same issue! I've posted the solution I used over at: MsBuild not finding publish profile
Basics were:
Install the Azure SDK 1.8 on the build server
Force the /P:PublishProfileRootFolder value to ensure MSBuild can locate the publish profile
Ensure that you have the Microsoft Web Developer Tools feature installed for Visual Studio. This was missing on my build agent but once I added it the TeamCity build worked just fine.
This can happen when the build target paths are missing from your MSBuild directory. Instead of trying to get those to line up on every developer machine, install the targets from the Nuget. That way it will always be the same for everyone, regardless of how their machine is setup.
I'm trying to get a Lightswitch Project into Teamcity and have tried the following runner types:
Visual Studio (sln)
MSBuild
Command line (ran MSBuild through the command line)
All 3 runner types gave me the same error when building the Lightswitch solution:
The "UnpackExtensionsToProjectDir" task failed unexpectedly. System.NullReferenceException: Object reference not set to an instance of an object.
Lightswitch has already been installed on the server. Have tried building the solution manually using Visual Studio on the server and it builds fine. Have also tried building the solution via the command line (using MSBuild) and it builds fine too.
Would like to ask if somebody was able to get Lightswitch building nicely on TeamCity. Cheers.
This is how you build via the Command line (using TeamCity)
Pre-requisites)
First make sure you have not checked in the extensions directory, this can cause issues when building.
Check that you have installed any visual studio extensions on the build machine .ie ExtensionsMadeEasy. You can test this by opening the solution in visual studio on the build machine and trying to do a build.
Lastly, in TeamCity do not use the msbuild task, use command line to call msbuild.
Step 1)
msbuild.exe mylightswitchproject.lsproj /p:OutDir=C:\test\stuff\;configuration=Release
Step 2)
Create a bat file to copy your output to the correct folder structure.
robocopy C:\test\stuff\bin C:\test\localrelease\bin *.* /MIR
robocopy C:\test\stuff\Resources C:\test\localrelease\Resources *.* /MIR
robocopy C:\test\stuff\Web C:\test\localrelease\Web *.* /MIR
robocopy C:\test\stuff\ C:\test\localrelease\ ClientAccessPolicy.xml
robocopy C:\test\stuff\ C:\test\localrelease\ default.htm
robocopy C:\test\stuff\ C:\test\localrelease\ Home.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ Login.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ LogOff.aspx
robocopy C:\test\stuff\ C:\test\localrelease\ Silverlight.js
robocopy C:\test\stuff\ C:\test\localrelease\ web.config
You can now take this folder and release it to the next environment.
Finally, if you want to create a web deployment package, out the box visual studio 2010 does not support this. However, you can copy this into an existing website then "Export" your application into a package that is then ready for web deployment via powershell.
The previous answers didn't work for us but Yaegor's answer provided some direction.
The issue we had was extensions are installed at the user level, not the system level. This meant the MSBuild process could not find the required extensions.
Our solution was to use a user account on the build server, log into account, setup VS.NET such that the LS project builds, and then switch the TeamCity agent service to use the new user account.
With this we were able to use the Solution runner (which is preferable to the CLI runner since it provides better logging and reporting).
For not Lightswitch-specific part: If command line works from console, but fails in TeamCity, most probably the issue is in the user or running as a service. You might try running TeamCity agent with the same environment.
When command line works you can then try MSBuild and Solution runners.
I ran into the same error when trying to set up an automated build for a lightswitch application using bamboo. Turned out to be the version of msbuild being called. If the 64bit version is called (from bamboo or the command line) I get the error:
UnpackExtensionsToProjectDir" task failed unexpectedly.
Switching to the 32bit version of msbuild fixes the problem.
32bit Path: 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe'
64bit Path: 'C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe'
I'm getting this error trying to run my Build thru TeamBuild in TeamExplorer on Visual Studio 2008.
On the Build Machine I installed VS SP1, Team Explorer, Silverlight 3 tools, and RIA Services.
I can compile no problem with Visual Studio on my machine and directly on the Build Machine. But I still cant compile on thru TeamBuild because it "says" I'm missing GetXapOutputFile target.
I checked C:\Program Files\MSBuild\Microsoft\Silverlight\v3.0\Microsoft.Silverlight.Common.targets file and it does have the GetXapOutputFile target:
<!--
============================================================
GetXapOutputFile
This stand-alone target returns the name of the built xap file.It
only makes sense to call this after a build
============================================================
-->
<Target
Name="GetXapOutputFile"
DependsOnTargets="_CreateSLProperties"
Outputs="$(XapOutputFile)"
/>
Any idea what I might be missing?
Hi I was trying a command line build and had same issue, this solved it for me:
Properties menu of 'xxx.Web' project, 'Silverlight Application' tab, remove the current item and add it again. After that, when building..., the error will go away. But I don't know why it is.
Found here: http://connect.microsoft.com/VisualStudio/feedback/details/698689/error-msb4057-the-target-getxapoutputfile-does-not-exist-in-the-project