Unable to publish on command line using publish profile #12490
Comments
|
Any help would be appreciated (including whether I may have posted this on the wrong project – I thought it was the right one when I posted). I'm totally stuck and can't find anything I'm doing wrong. |
|
@abbeycode thanks for contacting us. We'll route this to the right people and we'll come back to you. @vijayrkn can you take a look at this? |
|
@abbeycode can you pass /bl in the command line and please share the binlog(https://github.com/KirillOsenkov/MSBuildStructuredLog)? @wli3 This issue should be in the sdk repo. The code that deals with publish is in websdk. |
|
@abbeycode - I will take a look today and get back before the end of day. |
|
@abbeycode - I looked at the binlog but the publish profile is not imported
If you pass in the publish profile name, it should get imported here - Can you share the whole project & the exact command that you ran? Ideally you will only have to run this: |
|
I ran this command, though I also tried the one you gave with the same results ( I've attached the project, as it currently stands. I have also tried both commands without specifying the project name. |
|
The name of your profile is docker-image. So the command should be
|
|
Apologies, I've been trying so many permutations of naming and commands I forgot where I had left off. When I call |
|
I tried your sample. Here is what is needed: Change the profile to this. Replace the contents of the file in Properties\PublishProfiles\docker-image.pubxml Then run the command:
This should work. |
|
you were using a version of the profile for web. you need websdk for the profile you provided. Since your project file only has NetSdk, this should work. |
|
Thanks, that worked now! I had that publish profile because Visual Studio 2019 for Mac generated it, though, and it works fine from within Visual Studio. It seems like it should work in both places or in neither, right? Visual Studio doesn't work for the new publish profile now, either:
|
|
I will have to see how VS Mac is using this profile. Adding some additional properties might fix this. I will take a look. |
|
Fwiw, I'm seeing the same issue using VS 2019 16.7.2 on Windows 10 with a .net core 3.1 console app using a VS2019 generated stock FileProfile. No combination of command line dotnet build or dotnet publish will honor the FolderProfile set up for the main console application project in the solution. To make it even crazier, if you run VS -> Tools -> Command Line -> Developer Command Prompt to open a command session and then run dotnet publish you'll get published to a pubTmp folder instead, so there's something happening in the tools environment between the cli and ide. |
After applying the change recommended by Vijay, ie to change the contents of the default FolderProfile created by the VS Publishing Wizard, I was able to get command line dotnet publish to recognize the publishing profile. |
|
I noticed as well that the publish profile is ignored when using dotnet publish. It doesnt occure if you use build and set -p:DeployOnBuild=True but I build the project in my pipeline before this is clearly missing if it doesnt work with publish. |
|
I'm experiencing the same bug with dotnet publish using the PublishProfile. The following works and gets published to bin\Release\PublishOutput folder: However, using publish with the same profile ignores the publishUrl field in the profile: Here's what my pubxml file looks like: <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<PublishProvider>FileSystem</PublishProvider>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<TargetFramework>netcoreapp3.1</TargetFramework>
<RuntimeIdentifier>win7-x64</RuntimeIdentifier>
<ProjectGuid>40aa877f-1206-408a-8d96-ab1f8f84e75b</ProjectGuid>
<publishUrl>bin\Release\PublishOutput</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
<SelfContained>true</SelfContained>
<_IsPortable>true</_IsPortable>
<PublishReadyToRun>True</PublishReadyToRun>
</PropertyGroup>
</Project> |
|
I am encountering the same kind of problem. The command line: result: Plugin1 should be deployed to ....\PublishDir\win-x86\CoreApp\Plugins, but it is not. |
|
Similar issue here. The
My current <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<PublishProvider>FileSystem</PublishProvider>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>False</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<TargetFramework>netcoreapp3.1</TargetFramework>
<ProjectGuid>1f17a7a7-231d-4a50-9e05-35b5963f6e45</ProjectGuid>
<publishUrl>..\..\BuildOutput\Publish\API\</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
<SelfContained>false</SelfContained>
<_IsPortable>true</_IsPortable>
</PropertyGroup>
</Project>I have tried the .pubxml suggested by @vijayrkn as well, which works with
Some dotnet info: |
|
I'm also seeing this behavior. Once the file is generated: <?xml version="1.0" encoding="utf-8"?>
<!--
This file is used by the publish/package process of your Web project. You can customize the behavior of this process
by editing this MSBuild file. In order to learn more about this please visit https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FTP</WebPublishMethod>
<PublishProvider>AzureWebSite</PublishProvider>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish>http://blablabla.azurewebsites.net</SiteUrlToLaunchAfterPublish>
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<ProjectGuid>d26c8b50-b10b-4413-a0d1-490620379f51</ProjectGuid>
<publishUrl>ftp://blablabla.azurewebsites.windows.net</publishUrl>
<DeleteExistingFiles>False</DeleteExistingFiles>
<FtpPassiveMode>True</FtpPassiveMode>
<FtpSitePath>site/wwwroot</FtpSitePath>
<UserName>ssblazor\$ssblazor</UserName>
<Password>XXXXXX</Password>
</PropertyGroup>
</Project>I tried using it from the dotnet CLI (on my Mac) with:
and in both cases here is the output I'm getting: So the build is done, but the publication step is never executed, without any feedback as to why. I also did manage to deploy my project from my mac using the VSCode Azure extension, via the "Deploy to Web App..." option from my Azure resource explorer.
Any help would be appreciated as to why specifying a |
|
@Miiite So, I'm having the same issue personally on my Windows machine, however, in regards to your specific case, I think part of the problem is how you are specifying the publish profile. According to the dotnet publish command docs...
You are providing an actual path to the |
|
@willnationsdev I totally missed that part of the |
|
@vijayrkn ah okay. Excellent 👌 |
|
@vijayrkn I'm afraid that "merging" |
|
It still doesn't work for me. This is broken and there are multiple issues. I keep opening issues and getting fobbed off. Told I am complaining to the wrong group.
The missing command is a Visual Studio command Build -> Publish Solution -> ALL
I have tried numerous variations of this command: dotnet publish C:\Users\hallam\Work\mmm\Applications\meshhost\meshhost.csproj -c release /p:PublishProfile=publish-win-x64 They all fail in exactly the same way if I specify a non existent profile. |
|
Repo is https://github.com/hallambaker/Mathematical-Mesh Publish from inside VS 2022 works fine. Release x64 ..\..\Outputs\win-x64 FileSystem net6.0-windows win-x64 true True True True========== Build: 10 succeeded, 0 failed, 16 up-to-date, 0 skipped ========== This fails: dotnet publish mmm.sln -c release /p:PublishProfile=publish-win-x64a Fails with: C:\Program Files\dotnet\sdk\6.0.200\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.CrossTargeting.targets(27,5): error NETSDK1129: The 'Publish' target is not supported without specifying a target framework. The current project targets multiple frameworks, you must specify the framework for the published application. [C:\Users\hallam\work\mmm\Applications\MeshReferenceLibraryClient\MeshReferenceLibraryClient.csproj] The outputs have multiple framework targets. So the framework is specified in the .pubxml It is not possible to specify the framework directly because only the final assemblies and the windows specific libraries specify dotnet publish mmm.sln -c release /p:PublishProfile=publish-win-x64a -f net6.0-windows CSC : error CS2012: Cannot open 'C:\Users\hallam\work\mmm\Libraries\Windows\Goedel.Cryptography.Windows\obj\Release\net6.0-windows\Goedel.Cryptography.Windows.dll' for writing -- 'The process cannot access the file 'C:\Users\hallam\work\mmm\Libraries\Windows\Goedel.Cryptography.Windows\obj\Release\net6.0-windows\Goedel.Cryptography.Windows.dll' because it is being used by another process.' [C:\Users\hallam\work\mmm\Libraries\Windows\Goedel.Cryptography.Windows\Goedel.Cryptography.Windows.csproj] Given that this does not work, perhaps just admitting that it is broken would be the best course so folk don't have to waste even more time on it. Alternatively, if the Visual Studio side could have their build system report the actual command sent to the batch build app to the console, we could duplicate it. |
|
confirming that @lanorkin 's workaround works... manually adding update |
|
for me the |
|
It turns out this works for me: It did not work with publish though. |
This works for me. |
|
This is one of those things that seems like it should be easy and it's not. There are so many overlapping functionalities and syntax. It's quite the minefield. Over 4 years later new people are still showing up here with the same problem. Still, nobody from Microsoft has told us what commands are run when the |
|
In general VS is orchestrating a multi-stage operation, whereas dotnet is just running the Publish target. In VS, when you publish with a publish profile that profile is read and the properties in it are applied before the Publish target is run. This does not happen at the CLI (I have a very old PR we could possibly revive) and is one reason why behaviors differ. In addition, many of the behaviors and publish profiles that are supported in VS simply have no matching SDK or cross platform implementation - they were expressly designed to be run from within the context of a VS IDE experience and so cannot be run from the CLI. |
|
Ahh, that would explain things, there is a slot in the CLI to specify the publishing profile but if that profile is then ignored, that would explain it... I guess what I need to do is probably create a tool that creates a script that does the necessary... |
|
The confusing thing about Publish Profiles at the CLI is that they actually do something - they are like little property bags that get applied to your build. The problem is twofold:
|
|
Thanks @baronfel, this is all good information. My original query still stands. I can, and do, script a multi-stage operation. What series of commands can replicate the publish operation that VS does? |
|
Without knowing more about what kind of publish you are triggering from VS it's impossible to tell. What specifically are you doing in VS that you'd like to replicate? What kinds of projects, etc? Do you have a sample? |
|
Right now I am attempting to automate the publishing step in a solution with multiple projects so I don't need to publish them one by one. It's a series of desktop projects with folder publish profiles that look like this:
<?xml version="1.0" encoding="utf-8"?>
<!--
https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project>
<PropertyGroup>
<Configuration>Release</Configuration>
<Platform>Any CPU</Platform>
<PublishDir>Publish</PublishDir>
<PublishUrl>Publish</PublishUrl>
<PublishProtocol>FileSystem</PublishProtocol>
<_TargetId>Folder</_TargetId>
<TargetFramework>net8.0-windows</TargetFramework>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<SelfContained>false</SelfContained>
<PublishSingleFile>true</PublishSingleFile>
<IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>
<PublishReadyToRun>false</PublishReadyToRun>
<DeleteExistingFiles>True</DeleteExistingFiles>
</PropertyGroup>
</Project>I have tried running it a few different ways and I run into various errors. When it does complete it doesn't run my after publish steps. Currently I need to add these steps to my script so they will run from either the publish button, or the script. I was using some steps in the csproj for tracking hashes and making an installer like this: <!-- Create NSIS installer -->
<Target Name="BuildInstall" AfterTargets="Publish">
<Message Text="Running the build installer script:" Importance="High" />
<Exec Command="Publish\BuildInstall.cmd" />
</Target>
<!-- Hashing artifacts for verifiable builds -->
<ItemGroup>
<FilesToHash Include="Publish\*" />
</ItemGroup>
<Target Name="GetHash" AfterTargets="Publish">
<Message Text="Calculating hashes for all files in the publish directory: @(FilesToHash)" Importance="High" />
<GetFileHash Files="@(FilesToHash)">
<Output TaskParameter="Items" ItemName="FilesWithHashes" />
</GetFileHash>
<WriteLinesToFile File="BuildHashes.txt" Lines="@(FilesWithHashes->'%(FileHash) %(Identity)')" Overwrite="true" />
<Message Importance="Low" Text="@(FilesWithHashes->'%(FileHash) %(Identity)')" />
</Target> |
|
Ok, @baronfel said something about certain things not being applied during the original build step and that struck a chord. I merged the settings from the Then I ran: That allowed me to follow a standard build, test, publish deployment like what would happen on the build server. Now I'm getting what appears to be the same results from the publish button, a build script, and the GitHub action. This defeats the whole purpose of the PublishProfile being in a separate file. If you had multiple publish profiles then this would be more complicated. There would need to be a better way to apply the publish profile so it works without having those settings added to the csproj. Maybe I could get the same effect with the right set of switches instead of applying the settings to the csproj. |
|
@A9G-Data-Droid I found my old PR mimicking the VS behavior: #29817 This would eliminate the kinds of logical mismatches that you mention, however the other source of different behavior would remain: PublishProtocol types that are not available in the CLI would remain not available in the CLI. |
|
Thanks @baronfel ! I always enjoy seeing the internal struggles behind why things are the way they are. So where does this issue stand? Is there any movement in the sdk team to get cli\gui parity? In a world of automated deployments I would expect the VS GUI to be generating reproducible commands that will work on a headless build server. Take it a step further, Visual Studio could create the build script and run it when you press the button. I know that's a major structural change but it would ensure that the process was identical. It would remove all the mystery from the black box. This could also align cross platform build disparity. As far as PowerShell runs on any supported platform, so too would the build. I know, easier said than done. |
|
Triage: Assigned to nagilson to take a look in net10 at bringing back the prior PR on this. We won't implement all capability of VS but we can do better than we are as there are some reasonable properties we can read and apply. |
|
Any update to this issue? results in a successful build and publish to a local path but an empty path at the location specified in PublishUrl. I'm new to using the dotnet cli, but it seems a fundamental flaw to me? |
and others
I'm trying to automate the publishing of a .Net Core app on the Mac/Linux command line using the "dotnet" tool. No command I've tried has resulted in the project getting published to the folder the publish profile specifies. The publish profile works when I use Visual Studio for Mac to directly publish the project. I've tried many variations of both the
dotnet publish -p:PublishProfile=...command and alsodotnet build -p:DeployOnBuild=True -p:PublishProfile=.... It looks like it's silently ignoring the PublishProfile I give it, and indeed the output doesn't look materially different if I give it an intentionally bad path.I've tried specifying the csproj and not, pwd in the solution directory and in the project directory, and nothing seems to work except using Visual Studio instead of the dotnet CLI.
I'm running on a Mac running 10.15.5, and CentOS 7, both with dotnet 3.1.301.
My publish profile is the default folder publishing profile, named Properties/PublishProfiles/DockerImage.pubxml:
I see this output, indicating the app was published to the default directory instead of the docker-image folder I specified:
The text was updated successfully, but these errors were encountered: