I'm trying to use the Publishing tool from Visual Studio 2017. However, I guess Microsoft is now pushing out "servicing updates" for .NET core. It's complaining about a RuntimeIdentifier property being set during build or publish but not during restore. I didn't change anything. The Deployment Mode is set to Self Contained, so it should just include all dependencies and publish it to the server, right?
Severity Code Description Project File Line Suppression State
Error NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.1.3, but with current settings, version 2.1.3-servicing-26724-03 would be used instead. To resolve this issue, make sure the same settings are used for restore and for subsequent operations such as build or publish. Typically this issue can occur if the RuntimeIdentifier property is set during build or publish but not during restore.
This is a bug in VS2017 "15.8.2". Please see the answer to [VS2017 15.8.2 publishing error (.NET Core 2.1)
Related
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 know VS 2017 is only RC but there seem to be some major issues with migrating an ASP.Net Core 1.0 project to 1.1. The migration tool fails converting 2 of my 8 projects in the solution (I prefer to adopt a layered architectural approach for my projects) the sample project is located here. One project in particular is the class library I moved my web api controller methods into. In trying to re-create this class library it doesn't seem one is able to declare a controller class after installing Microsoft.AspNetCore.Mvc nuget. It is installed but the compiler is not finding the Controller, RouteAttribute classes, etc. The same issue occured with trying to setup a DI layer IServiceCollection. Nuget Microsoft.Extensions.DependencyInjection doesn't seem to be doing it.
The migration log quite honestly isn't really helping me. It seems to indicate an issue with my service project and the project.json file but as you can tell it is in the repository.
It feels like Microsoft is forcing us down the path of cramming all the "web" stuff into a single project file. Maybe these tools aren't far enough along yet but an RC would indicate they should be closer to ship ready?
ReciPiBook.Api
Message
src\ReciPiBook.Api\ReciPiBook.Api.xproj: Failed to migrate XProj project ReciPiBook.Api. 'dotnet migrate -s -p "C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Api" -x "C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Api\ReciPiBook.Api.xproj"' exited with error code 1.
src\ReciPiBook.Api\ReciPiBook.Api.xproj: Could not find file 'C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Services\project.json'. Migration failed.
src\ReciPiBook.Api\ReciPiBook.Api.xproj: Backing up C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Api\ReciPiBook.Api.xproj to C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\Backup\src\ReciPiBook.Api\ReciPiBook.Api.xproj.
src\ReciPiBook.Api\project.json: Backing up C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Api\project.json to C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\Backup\src\ReciPiBook.Api\project.json.
I can't directly speak to VS2017 as I'm staying away from it as even though it's a RC, the core tooling is in ALPHA. The VS 2015 core tooling is at least in a "RC" state (actually only preview).
In VS2015 I migrated from 1.0.x to 1.1 manually (per https://blogs.msdn.microsoft.com/dotnet/2016/11/16/announcing-net-core-1-1/):
Download the 1.1 sdk
Change your global.json "sdk":{"version": "1.0.0-preview2-1-003177"} (yes it's a different version string).
Update all the project.json package versions from 1.0 to 1.1 (some are preview some arn't). Just open up the nuget package manager, allow preview versions, then install all the updates.
Fix any of your project.json tool entries as the package manager clobbers those.
I am trying to setup a CI build using Visual Studio Online but I am getting the following error about the NuGet client:
The 'System.Net.Http 4.0.0' package requires NuGet client version '3.0' or above, but the current NuGet version is '2.8.60318.667'.
Solution builds and deploys fine directly from my Visual Studio 2015 itself but I am unable to get it to build in VSO. Does anyone if NuGet 3.x is installed on hosted build controllers or if I can supply my own copy along with my solution?
It's hard to guess by the question what build tasks are used. If you use VSBuild/MSBuild, it is only possible to turn "Restore NuGet packages" on, but there's no influence on the NuGet version.
However, if you turn this checkbox off, and instead add another build task called NuGet Installer before the main build step, you'll be able to provide a custom path to NuGet.exe. In the case of hosted build agent, the most obvious option is to commit required version of NuGet.exe to the repo, and then reference it from the build step:
Sounds like a hack, but it might work in your case.
I'm trying to configure Visual Studio Online to continuously deploy my ASPNET 5 application to an Azure webapp as described in this tutorial from the Team Foundation Build docs: https://msdn.microsoft.com/Library/vs/alm/Build/azure/deploy-aspnet5
I have followed all the steps and everything is working great. By default this script deploys a build of my app that targets the full .Net 4.5.1 DNX so I decided to try and modify it to deploy for .Net Core.
The build script creates its deployment package by calling: msbuild.exe /t:Build,FileSystemPublish
After turning up log verbosity and reading through the relevant msbuild files I have learned the following:
The "Build" target ultimately uses dnx.exe to compile the project. Because the project.json file includes both dnx451 and coreclr TFMs this step produces build output for both frameworks - so far so good.
However, the FileSystemPublish target seems to only output an msdeploy package that targets the .Net 4.5.1 runtime. From the logs I could see executing the FileSystemPublish target ultimately issues a "dnu publish" command and in my cases passes "dnx-clr-win-x86.1.0.0-beta6" as the -runtime parameter. When I followed the breadcrumbs to find out where it was getting the value "dnx-clr-win-x86.1.0.0-beta6" from I eventually ended up in the "GetRuntimeToolingPath" task in Microsoft.DNX.Tasks.dll. This task seems to look in global.json to determine the correct runtime to use but strangely appears to internally override this value with "x86" and "clr" before creating the return string.
If I have interpreted things correctly, it seems that the FileSystemPublish target (in Microsoft.DNX.Publishing.targets) is essentially (indirectly) hard wired to use the x86, full .Net framework DNX when it produces its package output. At this point I am stuck for how to get this build process to produce a .Net Core package.
My question is why would FileSystemPublish be coupled to the x86 full .Net DNX and given this appears to be the case (unless I am mistaken) what is the recommended way to produce an msdeploy package for an ASPNET 5 app that targets .Net core?
EDIT:
For now I have a workaround. I can pass /p:RuntimeToolingDirectory="C:\Users\buildguest\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta6" as a parameter to msbuild.
This overrides the default logic in the GetRuntimeToolPath and forces it to use .Net Core. This works but feels like a hack so I'm leaving the question open for a better answer.
To publish Core CLR, you can pass the msbuild parameter 'PublishDNXVersion' as dnx-coreclr-win-x64.1.0.0-beta6.
msbuild <project>.xproj /p:deployOnBuild=true;PublishDNXVersion=dnx-coreclr-win-x64.1.0.0-beta6
From the Old Azure portal within the Web App section of it on the Dashboard page of your particular Web App.
[deep breath]
On the right hand side is a section that says "set up publishing with visual studio online". Clicking on that link will walk you through the necessary steps to set up continuous deployment from a visual studio online repository (either git or tfs based)
Since that is a mouthful, I have provided a link to a tutorial which walks you through the entire process: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-continuous-delivery-use-vso/#step3
Had the same problem with .NET Core RC2-preview1 tooling. My solution: Add SDKToolingDirectory to my .xproj with a proper path to .NET Core installation:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">14.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<SDKToolingDirectory>C:\Program Files\dotnet</SDKToolingDirectory>
</PropertyGroup>
I had some luck with this by passing the following parameters into the Bundling step of my Visual Studio Online build process:
/p:Bundle64BitRuntime=true /p:BundleCoreClrRuntime=true
This causes my publish to leverage the 64 bit CoreCLR Runtime when it runs through msbuild.exe.
I figured this stuff out by digging through the Microsoft.DNX.Publishing.targets file (found at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web) and looking for variables I could pass in as properties. Regarding runtime, this seems to be an interesting snippet:
<GetRuntimeVersion
Condition="'$(IgnoreDNXRuntime)' != 'true'"
RuntimeVersionOverride="$(PublishDNXVersion)"
TargetDNXVersion="$(_DefaultDNXVersion)"
RuntimeToolingVersion="$(RuntimeToolingVersion)"
Want64Bit="$(Bundle64BitRuntime)"
WantCoreClr="$(BundleCoreClrRuntime)">
<Output PropertyName="FinalPublishVersion" TaskParameter="RuntimeVersion"></Output>
</GetRuntimeVersion>
There's probably a little bit(?) of risk here in terms of future proofing your build routine against future changes to variables names. But, you know, beta software and all that :)
Good luck!
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.