I created an Azure Devops Build pipeline and i am trying to build my ASP.NET MVC and Angular hybrid site project on bitbucket (git).
The project first gets checked out, and nuget restores the necessary packages, and then the .NET builds. I used windows 2019 as azure pipeline agent for the build to succeed. however, Its taking about 7 minutes to complete, whilst running the tasks (besides .Net) on a ubuntu agent is much faster! takes around 2 mins instead!
Therefore, I'd like to use ubuntu, but im running into an issue with the MSBuild task...
"/home/vsts/work/1/s/Bobby.ProjectA/Bobby.ProjectA.csproj" (default target) (1) ->
(KillVBCSCompilerAndRetryCopy target) ->
/home/vsts/work/1/s/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8/build/net45/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props(23,5):
error MSB4044: The "KillProcess" task was not given a value for the required parameter "ImagePath". [/home/vsts/work/1/s/Bobby.ProjectA/Bobby.ProjectA.csproj]
According to this post, VBCSCompiler.exe continues running from the Compiler Nuget package (nuget restore task?) so it locks the src folders and prevented future builds from running, e.g. causing error like this:
/home/vsts/work/1/s/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8/build/net45/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props(17,5):
warning MSB3021: Unable to copy file "/home/vsts/work/1/s/packages/Microsoft.Net.Compilers.2.4.0/build/../tools/csc.exe" to "/bin/roslyn/csc.exe". Access to the path '/bin/roslyn' is denied. [/home/vsts/work/1/s/Bobby.ProjectA/Bobby.ProjectA.csproj]
So the solution would be to kill the VBCSCompiler.exe but since i cant actually access the hosted machine during the build, im not sure how to do that.
screenshot of my pipeline so far:
Am i facing a dead-end path here with this approach? The build runs fine on windows 2019 but it just takes too long, so thats why if i can make it run on ubuntu successfully that would be great!
You can have a try with below workarounds:
1,Set MSBUILD arguements /p:UseSharedCompilation=false.
You can add above arguement to the msbuild arguements field of the msbuild task. See here.
2,Upgrade Microsoft.CodeDom.Providers.DotNetCompilerPlatform nupkg to the latest and remove Microsoft.Net.Compilers nupkg from your project. See here for more information.
3, Try Specifing the TTL of Roslyn compiler server.
You can define a pipeline variable VBCSCOMPILER_TTL on the Variable tab to specify a shorter idle time for VBCSCompiler.exe
Or you can add <providerOption name="CompilerServerTimeToLive" value="[num of seconds]" /> under system.codedom/compilers/compiler in the config file. See here for more information.
4, Use CheckIfShouldKillVBCSCompiler target:
You can try add below to your csproj file:
<Target Name="CheckIfShouldKillVBCSCompiler">
<PropertyGroup>
<ShouldKillVBCSCompiler>true</ShouldKillVBCSCompiler>
</PropertyGroup>
</Target>
See here.
The build on Ubuntu 20 finally worked! I don't know why removing these lines resolved the VBCSCompiler issue, but by doing so, the msbuild completed successfully on Ubunutu 20 agent!!
Remove the following lines from the .csproj file:
<Import Project="..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props')" />
<Error Condition="!Exists('..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props'))" />
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
To give some context to the answer, this post here indicated that converting from MSBuild-Integrated Package Restore to Automatic Package Restore (nuget restore task) implied that the Microsoft.Net.Compilers <Import> and <Error Condition> snippets are no longer relevant/needed in the .csproj file.
Related
I upgraded Microsoft.AspNetCore from 2.0.3 to 2.0.5 and my WebAPI project, although running successfully locally, fails to start in production (IIS). Everything was fine in production until this upgrade. The error message produced in the log directory is as follows:
Error:
An assembly specified in the application dependencies manifest (MyProject.WebAPI.deps.json) was not found:
package: 'Microsoft.AspNetCore.Mvc.Abstractions', version: '2.0.2'
path: 'lib/netstandard2.0/Microsoft.AspNetCore.Mvc.Abstractions.dll'
This assembly was expected to be in the local runtime store as the application was published using the following target manifest files:
aspnetcore-store-2.0.5.xml
Could someone explain to me the details of exactly what this means? I assume it's a version mismatch of sorts, but why is this occurring? I thought the latest stable releases of NuGet packages weren't supposed to have such issues.
I was able to resolve the issue by downgrading Microsoft.AspNetCore.All from 2.0.5 to 2.0.3, but would like to find a better solution to the issue so I can use the most up-to-date version of this package.
Development machines usually have the SDK installed but on production the runtime only.
Add the following to your .csproj file and publish again.
<PropertyGroup>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
Sometimes this is related to the Startup Project, For example if the migration is a class library in Azure Functions project. You have to make sure when you run Add-Migration while the EF Library project is selected as Startup Project.
For me, the marked answer didn't solve the issue. My issue was when trying to Add-Migration
Add-Migration -Name initial-migration -Context Mysln.Data.MyDbContext -StartupProject Mysln -Project Mysln.Core
And the error was like this:
I solved it by downgrading all my Entityframework packages to 2.0.0 instead of the latest 2.2.0-preview one.
If you have more than one project in your solution like me:
and if you want to scaffold dbcontext in your "non startup" project (InstantOrder.Functions.Data in my case)
then you should add the -StartupProject parameter of the Scaffold-DbContext command like this -
Scaffold-DbContext "Server=..." -Project InstantOrder.Functions.Data -StartupProject InstantOrder.Functions.Data
I know this may be old, but just in case it can help some one else, this one worked for me:
Adding:
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
To the PropertyGroup in the .csproj file.
To solve the first half of the error message, An assembly specified in the application dependencies manifest (…) was not found be sure to always use the publish output when deploying to a target sever.
For a self-contained application it can be found in
bin\Release\netcoreapp2.0\win81-x64\publish
or for framework-dependent deployments in
bin\Release\netcoreapp2.0\publish
The output in the directories above are meant to be used in development only, since they are specific to machine and user configuration built with.
Taken from a related answer.
2 cents: If you just take from the build folder, the dlls for the dependency aren't provided. If you publish the folder, they are. This was the fix for me.
I had this error however my solution was somewhat different from what was posted above. My problem was that I was deploying via a zip file and while building the zip file I wasn't including sub directories therefore required files were not being included.
So if you are publishing via a zip file make sure to include all sub folders while building the zip.
I got this error while running Scaffold-DbContext command on the Library project.
Solution:
Remove the Azure Function project from the solution, and then run this command.
After that, use add an existing project feature to add the Azure Function project again in the solution.
The correct .NET Core runtime was not installed on my PC. I had NETCore.App 2.1 and 2.2, but the project was targeted to 2.0.
dotnet --list-runtimes
I installed the correct runtime from the dot.net site and it resolved the issue.
In most case you get that error because there's misalignment of versions.
I changed the Microsoft.VisualStudio.Web.CodeGeneration.Design version, an it worked.
Before
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="3.1.0" />
After
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.2.4" />
This happened to me when I published my Lambda to AWS after renaming the project. I deleted both the obj and bin folders, rebuilt, republished and that fixed it.
I changed filters in Yaml.
Had projects called TestHelper etc...
Testrunner tried to run projects without tests, and the build was flagged as failed.
Added:
!**\*Helper*.*
To:
- task: DotNetCoreCLI#2
inputs:
command: 'test'
projects: |
**\*test*.dll
!**\*TestAdapter.dll
!**\obj\**
!**\*TestPlatform*.dll
!**\*Testing*.*
!**\*TestHost*.*
!**\*Helper*.*
I have the following setup: ASP.Net MVC .Net 4.0 solution with 5 projects in it, and several solution configurations (Site1-Stage, Site1-Live, Site2-Stage, etc). The reason for this is simple - we deploy same codebase to multiple servers with different config settings.
To manage these configurations, I use the approach described by Troy Hunt in his You're deploying it wrong! TeamCity, Subversion & Web Deploy part 1: Config transforms article. In 2 words - I do NOT have web.config in my SVN repo, instead I have Web.Base.Config, Web.Site1-Stage.Config, etc and XmlTransformation task in project AfterBuild target. During the build, the required web.config is generated based on selected configuration:
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterBuild">
<TransformXml Source="Web.Base.config" Transform="Web.$(Configuration).config" Destination="Web.config" StackTrace="true" />
</Target>
Here comes the problem: when I'm execute MSBuild like this:
msbuild MySolution.sln /P:configuration=Site1-Stage /t:rebuild
all goes well, web.config is properly generated for the Site1-Stage configuration. However, if I run this command:
msbuild MySolution.sln /P:configuration=Site1-Stage /t:rebuild /P:DeployOnBuild=True
I get the following error:
"MySolution.sln" (rebuild target) (1) -> "MySolution\MyWebProj.csproj"
(Rebuild target) (3) -> (PreTransformWebConfig target) -> C:\Program
Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.5\Web\Microsoft.Web.Publishing.targets(1399,5):
error : Copying file Web.config to
obj\Site1-Stage\TransformWebConfig\original\Web.config failed. Could
not find file 'Web.config'. [MySolution\MyWebProj.csproj]
I tried to explicitly add "AfterBuild" target into MSBuild command line:
msbuild MySolution.sln /P:configuration=Site1-Stage /t:rebuild,AfterBuild /P:DeployOnBuild=True
but it resulted in the same error.
Why do I need this: it's a very isolated example, and in reality I'm trying to setup automated publishing from TeamCity CI server. I think if I add new build step with "Visual Studio (sln)" runner BEFORE my current publishing step, that would work, it will first rebuild the project (and generate web.config) - and then publish. However, i have lots of publishing steps (around 20 now) and I would like to avoid that. My understanding is that "Publish" process does the build as part of it, so I would like to "reuse" that.
Question is: how should I modify my MSBuild command line to force config transformation to happen?
Thank you.
Maybe use "BeforeBuild"?
BTW do you have web.config included in csproj? I believe most publish activities relies on items in project rather than in folder. You can include web.config in project, while still have excluded it from source control.
Heads up: I'm a total MSDeploy noob. In fact, this is my first attempt at creating a msbuild script and I'm only recently started looking into msdeploy.
Now that that's out of the way, I'm writing a build script to compile and package my ASP.Net webforms application. The script can compile the solution, however, I'm getting the following error when attempting to package:
Microsoft.Web.Deployment.DeploymentException: The library 'Microsoft.Data.Tools.Schema.DbSqlPackage, Version=10.3.0.0, ...' could not be loaded.
I've searched the web but I can't seem to find any instances of this issue (specific to the missing DbSqlPackage.dll). I assume this has something to do with the ability to package and deploy databases referenced in the solution.
I am using MSDeploy V3 and MSBuild v4.0.30319. The Package target of the .build file is as follows:
<Target Name="Package" DependsOnTargets="Compile">
<PropertyGroup>
<PackageDir>%(PackageFile.RootDir)%(PackageFile.Directory)</PackageDir>
<Source>%(Website.FullPath)</Source>
<Destination>%(PackageFile.FullPath)</Destination>
</PropertyGroup>
<MakeDir Directories="$(PackageDir)" />
<Exec Command='"#(MsDeploy)" -verb:sync -source:iisApp="$(Source)" -dest:package="$(Destination)"' />
I am not trying to include any databases and I would be happy if there is a switch that I can set to bypass the error all together. However, if anyone knows how to FIX and not just avoid the issue, that would be preferred.
Thanks in advance.
Vinney
I tried to repair the installation of MS Web Deploy but no dice. Except, my filter terms "web deploy" turned up another item in my installed programs: "Web Deploy dbSqlPackage Provider" (or something along those lines... it's late). The build/package completes after removing this program.
It only took me half a day to find this solution... oh well!
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)" />
I am trying to use MSBuild to build a solution with a specified target platform (I need both binaries, x86 and x64). This is how I tried it:
C:\WINDOWS\Microsoft.NET\Framework\v3.5>MsBuild SolutionPath\Solution.sln /t:Rebuild /p:Configuration=Release /p:Platform="x86"
However the build always fails if the platform is different from "Any CPU". What am I doing wrong?
This is the while output MSBuild prints:
C:\WINDOWS\Microsoft.NET\Framework\v3.5>MsBuild
SolutionPath\Solution.sln /t:Rebuild
/p:Configuration=Release
/p:Platform="x86" Microsoft (R) Build
Engine Version 3.5.30729.1 [Microsoft
.NET Framework, Version
2.0.50727.3082] Copyright (C) Microsoft Corporation 2007. All rights
reserved.
Build started 1.7.2010 8:28:10.
Project "SolutionPath\Solution.sln" on
node 0 (Rebuild targe t(s)).
SolutionPath\Solution.sln : error
MSB4126: The specified sol ution
configuration "Release|x86" is
invalid. Please specify a valid
solution c onfiguration using the
Configuration and Platform properties
(e.g. MSBuild.exe Solution.sln
/p:Configuration=Debug
/p:Platform="Any CPU") or leave those
prope rties blank to use the default
solution configuration. Done Building
Project "SolutionPath\Solution.sln"
(Rebuild t arget(s)) -- FAILED.
Build FAILED.
"SolutionPath\Solution.sln" (Rebuild
target) (1) ->
(ValidateSolutionConfiguration target)
-> SolutionPath\Solution.sln : error MSB4126: The specified s olution
configuration "Release|x86" is
invalid. Please specify a valid
solution configuration using the
Configuration and Platform properties
(e.g. MSBuild.ex e Solution.sln
/p:Configuration=Debug
/p:Platform="Any CPU") or leave those
pro perties blank to use the default
solution configuration.
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.03
If I try to build it for x86/x64 with devenv it works perfectly, however I am trying to set up a build server without installing all the necessary versions of Visual Studio. By the way, if there is a better free tool (that supports .NET framework 4) out there, I'd love to hear about it.
In MSBuild or Teamcity use command line
MSBuild yourproject.sln /property:Configuration=Release /property:Platform=x64
or use shorter form:
MSBuild yourproject.sln /p:Configuration=Release /p:Platform=x64
However you need to set up platform in your project anyway, see the answer by Julien Hoarau.
If you want to build your solution for x86 and x64, your solution must be configured for both platforms. Actually you just have an Any CPU configuration.
How to check the available configuration for a project
To check the available configuration for a given project, open the project file (*.csproj for example) and look for a PropertyGroup with the right Condition.
If you want to build in Release mode for x86, you must have something like this in your project file:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
...
</PropertyGroup>
How to create and edit the configuration in Visual Studio
(source: microsoft.com)
(source: msdn.com)
(source: msdn.com)
How to create and edit the configuration (on MSDN)
If you're trying to do this from the command line, you may be encountering an issue where a machine-wide environment variable 'Platform' is being set for you and working against you. I can reproduce this if I use the VS2012 Command window instead of a regular windows Command window.
At the command prompt type:
set platform
In a VS2012 Command window, I have a value of 'X64' preset. That seems to interfere with whatever is in my solution file.
In a regular Command window, the 'set' command results in a "variable not defined" message...which is good.
If the result of your 'set' command above returns no environment variable value, you should be good to go.
Hopefully this helps someone out there.
For platform I was specifying "Any CPU", changed it to "AnyCPU" and that fixed the problem.
msbuild C:\Users\Project\Project.publishproj /p:Platform="AnyCPU" /p:DeployOnBuild=true /p:PublishProfile=local /p:Configuration=Debug
If you look at your .csproj file you'll see the correct platform name to use.
For VS2017 and 2019... with the modern core library SDK project files, the platform can be changed during the build process. Here's an example to change to the anycpu platform, just before the built-in CoreCompile task runs:
<Project Sdk="Microsoft.NET.Sdk" >
<Target Name="SwitchToAnyCpu" BeforeTargets="CoreCompile" >
<Message Text="Current Platform=$(Platform)" />
<Message Text="Current PlatformTarget=$(PlatformName)" />
<PropertyGroup>
<Platform>anycpu</Platform>
<PlatformTarget>anycpu</PlatformTarget>
</PropertyGroup>
<Message Text="New Platform=$(Platform)" />
<Message Text="New PlatformTarget=$(PlatformTarget)" />
</Target>
</Project>
In my case, I'm building an FPGA with BeforeTargets and AfterTargets tasks, but compiling a C# app in the main CoreCompile. (partly as I may want some sort of command-line app, and partly because I could not figure out how to omit or override CoreCompile)
To build for multiple, concurrent binaries such as x86 and x64: either a separate, manual build task would be needed or two separate project files with the respective <PlatformTarget>x86</PlatformTarget> and <PlatformTarget>x64</PlatformTarget> settings in the example, above.
When you define different build configurations in your visual studio solution for your projects using a tool like ConfigurationTransform, you may want your Teamcity build, to build you a specified build configuration. You may have build configurations e.g., Debug, Release, Dev, UAT, Prod etc defined. This means, you will have MSBuild Configuration transformation setup for the different configurations. These different configurations are usually used when you have different configurations, e.g. different database connection strings, for the different environment. This is very common because you would have a different database for your production environment from your playground development environment.
They say a picture is worth a thousand words, please see the image below how you would specify multiple build configurations in Teamcity.
In the commandline input text box, specify as below
/p:OutputPath=Publish;Configuration=Dev
Here, I have specified two commandline build configurations/arguments OutputPath and build Configuration with values Publish and Dev respectively, but it could have been, UAT or Prod configuration. If you want more, simply separate them by semi-colon,;
There is an odd case I got in VS2017, about the space between ‘Any’ and 'CPU'.
this is not about using command prompt.
If you have a build project file, which could call other solution files. You can try to add the space between Any and CPU, like this (the Platform property value):
<MSBuild Projects="#(SolutionToBuild2)" Properties ="Configuration=$(ProjectConfiguration);Platform=Any CPU;Rerun=$(MsBuildReRun);" />
Before I fix this build issue, it is like this (ProjectPlatform is a global variable, was set to 'AnyCPU'):
<MSBuild Projects="#(SolutionToBuild1)" Properties ="Configuration=$(ProjectConfiguration);Platform=$(ProjectPlatform);Rerun=$(MsBuildReRun);" />
Also, we have a lot projects being called using $ (ProjectPlatform), which is 'AnyCPU' and work fine. If we open proj file, we can see lines liket this and it make sense.
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
So my conclusion is,
'AnyCPU' works for calling project files, but not for calling solution files,
for calling solution files, using 'Any CPU' (add the space.)
For now, I am not sure if it is a bug of VS project file or MSBuild.
I am using VS2017 with VS2017 build tools installed.
In Visual Studio 2019, version 16.8.4, you can just add
<Prefer32Bit>false</Prefer32Bit>