Context:
I have a MAUI app I have been working on which, for now, only has Windows listed as a TargetFramework in the project file. Until VS2022 17.4 arrived I was able to build and publish this using a publish profile (pubxml) file.
The problem:
Now that 17.4 has dropped, trying to publish the application fails because it no longer uses the pubxml file unless you have more than one platform specified in the TargetFrameworks. I can still publish the app via the command line using -r win10-x64 instead of -a x64 but am completely unable to publish without at least adding android as a TF.
Has anyone else seen this and found a better workaround?
STR:
Create a new MAUI app, enter the project file and remove the line specifying the non-Windows TFs, try to publish using gui.
Related
I wanted to start coding something using .NET MAUI, so I updated my VS2022 to "Version 17.1.0 Preview 6.0".
Then I installed these features using "Visual Studio Installer" as suggested in https://learn.microsoft.com/en-us/dotnet/maui/get-started/installation
Unfortunately when I create a basic MAUI app, I get several errors like this:
Error NU1012 Platform version is not present for one or more target
frameworks, even though they have specified a platform: net6.0-android
On developer command line I tried running dotnet workload list and got
android
ios
maui-android
maui-maccatalyst
If I try to install some other workload (eg maui or maui-windows) I get an error stating
Unable to download manifest microsoft.net.workload.emscripten:
microsoft.net.workload.emscripten.manifest-6.0.200 has not been found
on NuGet feeds https://api.nuget.org/v3/index.json, C:\Program Files
(x86)\Microsoft SDKs\NuGetPackages"
I've also tried to completely remove and reinstall VS2022, without any luck.
I've then tried to run maui-check but when it tries to download Recommendation: Download .NET SDK (6.0.200) the exe is not valid and the task fails.
Worst part: I tried to install a fresh VS2022 preview on a different pc and everything works flawlessly... but I need it to work on my developmente pc!
.
On "Hosted VS2017" and self-hosted build agent (Windows Server 2012 R2), running dotnet publish with a publish profile specified fails with:
C:\Program
Files\dotnet\sdk\2.1.502\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(198,5):
error NETSDK1047: Assets file
'C:\agent_work\11\s\\obj\project.assets.json' doesn't have a
target for '.NETCoreApp,Version=v2.1/win-x64'. Ensure that restore has
run and that you have included 'netcoreapp2.1' in the TargetFrameworks
for your project. You may also need to include 'win-x64' in your
project's RuntimeIdentifiers.
On local dev server (Win10, VS2017, many different .net sdk versions) when I dotnet publish with the exact same command line, everything works great.
I have tried everything from updating VS2017, installing the exact version of .net core SDK and runtime that we're targeting, updating the build agent, windows updates... Nothing seems to help. I can't understand why it's having different behavior.
The publish profile is a FileSystem profile and has the following two elements specified:
<TargetFramework>netcoreapp2.1</TargetFramework>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
The command line looks this: "C:\Program Files\dotnet\dotnet.exe" publish "C:\agent\_work\11\s\Source\TheProject.csproj" --no-build -c Release -f netcoreapp2.1 /p:PublishProfile="Publish Release To Filesystem.pubxml" -o C:\agent\_work\11\a\Website -v d
Does anyone have a clue what I can do to get this working?
This turns out to be all about the Runtime Identifier. The confusion arose because I assumed building and publishing from dotnet-cli was as simple as building and publishing from Visual Studio. Visual Studio's publish was doing a full restore/build with its publish, and the publish profile had the <RuntimeIdentifier> set.
I was doing several things wrong. I wasn't including -r win-x64 to the restore and build tasks, and I was using dotnet publish --no-build. So that's where one mismatch came from. The next was that I was running dotnet test after build and before publish. That was wiping out some things that publish needed, not sure what though.
I changed dotnet test to include -p:RuntimeIdentifier=winx64 since apparently it uses -r for reporting output (apparently they're adding -runtime in 2.2).
Some things I learned in the process, dotnet-cli does NOT work well with .sln files, at least in build agent's. It seems to have a big problem with file locks and shared processes. Trying to optimize build tasks to minimize work with the dotnet-cli is a major pain in the ass.
I think Jay covered this in the other answer, but to clarify what worked for me was running:-
dotnet restore <path/to/.sln> -r linux-x64
just before running the dotnet msbuild command. (Obviously replace linux-x64 with your target).
I try publish ASP .NET Core2 app.
App is work in visual studio 2017
dotnet build -c Release completed without error
dotnet publish -c Release
Has error
Cannot find compilation library location for package 'Hangfire.MemoryStorage'
But Hangfire.MemoryStorage is _Libs\Hangfire.MemoryStorage.dll not a package
build compiles all your .cs files mainly
publish also compiles all your view files into a single .dll file. So it validates your views as well.
So, If you have an error only in the publish and not in the build, there most probably must be a bug somewhere in your views. Even if the app worked in visual studio, there might be a run time issue somewhere if the bug is in a view.
Regarding the Hangfire.MemoryStorage library. The last update was three months ago. There have also been past issues with this library related to the code not updated for the latest version of .net core. So, I don't think he has released the stable version for .net core 2.0 yet (assuming you have the latest version of the app installed).
I just converted a project from MVC 4 to ASP.NET Core 1.0. This project does some pinvoke on a 32bit dll and when I try to debug it, I get that bad image exception.
If I deploy it using dotnet publish -c Release -r win7-x86 it works perfectly fine, but I can't debug it or run through visual studio.
You need to either publish the app as standalone app 32bit or, if it's a shared framework app, then you need to start it with a 32 bit dotnet.
If you already have the app running in 32 bit mode, then you can attach VS to it.
If you want VS to always use the 32 bit dotnet then you have to uninstall the dotnet in program files (or just remove it from the system PATH) and then install a dotnet that's 32 bit, making sure it's on the PATH. It's important to note that system PATH takes priority in Windows so adding something to the user's PATH will not work unless you remove the old one.
PS: I assume you're running on a 64 bit OS. Otherwise, you get the 32 bit dotnet by default.
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.