Dotnet publish no-build switch disappeared #7521
Comments
|
@dsplaisted @nguerrera @eerhardt Is there a way to trigger a publish without build? |
|
@hongdai It would be useful if you can share how you used this flag. I think there was some debate about whether it is still useful. |
Agreed. Getting all the use cases for why this switch is useful helps us understand whether to put it back or not. One of the use cases I've recently encountered was the F# team (specifically @KevinRansom) was using this switch to publish a project's references, but he didn't want the project's output (its .dll) published. The replacement in that case is to add the MSBuild property FYI - @livarcocc and @piotrpMSFT, we could use this switch in the dotnet/cli ourselves in https://github.com/dotnet/cli/blob/rel/1.0.0/src/redist/redist.csproj. Then we wouldn't need to delete the |
|
It will be great to have We do the following in vstest repo:
Update: our build process had a race condition on resources files which was slowing down the process. As @eerhardt notes below, msbuild incremental build does kick in, it is not a significant overhead for us now. |
Why is incremental building not kicking in? MSBuild knows if a project is already built, and doesn't need to build it again. |
|
@piotrpMSFT We used to have our own publish target and run in AfterBuild. Without no-build switch, the publish target will invoke a build and cause a infinite loop, unless we add a condition. dotnet pack still supports no-build switch. I think the usage should be similar. |
|
+1 As I see it, there should be an option to have the output of a build be the output of what you call "publish". I'd say that this should be the default behavior but that is debatable. As far as I understand it from reading the issues and documentation, this discrepancy is a workaround to speed up the build time of console apps (e.g. use the nuget cache to save on checksum calculations?!). .Net is used for more than console apps and as such that workaround is not applicable to hosts different than For such cases, I've managed to make For me the no-build switch is a workaround. Ideally I would like you to support the case where the output of the build contains all the required runtime dependencies. |
|
Same issue here -- Why wasn't this BREAKING CHANGE announced on the announcement repo? I've just converted all our stuff to csproj and now this broke our whole ci/azure setup. We have 3 deployments setup on AppVeyor for a single solution, so we have 3 configurations that do the following:
|
|
Let's say it is kicking in (which I think it is) -- just the fact the it has to run msbuild, scan for the project(s), see if they need building, etc -- all takes time; time I don't want to be waiting for my CI to finish. For example, on one of my projects it takes about 23s to build it the first time and then 9s to build it the second time (the one that used to be skipped). Yeah, 9s isn't that long in the scheme of things, but it isn't nothing either. Also, given this flag is seemingly just a simple -- don't run msbuild -- I don't understand why it is so desirable to not support it? |
|
I think this is caused by the current situations that large package graphs (netstandard.library, m.n.app) slow down msbuild projects which is causing project references to slow down linear (1 project 1 sec, 10 projects 10 sec) and has been discussed in https://github.com/dotnet/cli/issues/5918, #1116, dotnet/msbuild#1276 and maybe even more. Even if build targets are avoided for publish, I believe |
@dasMulli hit the nail on the head. What does
Doing a Another thing to understand is that So the reason there is push back to supporting it is because it isn't clear what the option is supposed to do/mean. And once we settle on a definition, the next decision to make is - is the scenario we are enabling a high-priority scenario that many customers need? |
|
From that description why wouldn't |
|
Like @dasMulli says above, there are shared targets between
If you are interested in tracking down why the 2nd time is taking 9s, you can pass First TimeSecond TimeAs you can see, (Now granted, we probably have some sort of perf bug in Anyway, I'd be interested in learning what you find is taking 9s on your 2nd build. I'm sure you would be too 😉. |
|
Thanks for the information! I will try that out and see what the bottleneck is. As for the Basically I just want to avoid doing duplicate work. |
|
The result of |
That different discussion is here; dotnet/msbuild#2015 |
|
Here is my use case. I'm working on adding CI to our process for an ASP.Net Core site we are building. I want to be able to build once, test those binaries, and then publish the tested binaries as part of the CI workflow. This flag still works with |
|
To my mind, publishing a project should operate on it's built assets - therefore publishing is obviously dependent on a build having occurred! I think it would be rare in the world of CI that you would want to publish something from a vanilla state (i.e without already having just done a build to test the assets you are publishing). So the reason for wanting to specify "no build" is because at the point of the workflow you want to publish you have already done the build - mixed in with the fact that an "incremental build" doesn't seem to be as fast as it should be. If an incremental build truly was neglible (i.e zero overhead if build already done) then I don't think this would be such an issue. I guess it's debatable what an acceptable level of overhead would be. I'd be ok if, for large projects, an incremental build didn't incur more than a couple of seconds penalty when nothing has changed. If it takes more than that, and you know ahead of time nothing has changed then you can see why people would be looking to use that "no build" flag if it's available. This brings me to another point - the willingness to remove this and break peoples CI's processes to seemingly force some feedback on the issue seems a little bit hostile :-/ don't you think?
I am wondering why it should need to look at references at this point? If the build has already occurred, then the build output (including referenced assemblies / content files etc that had "copy to output") has already been produced. In other words, the assets are already all produced and publish just needs to do something with those existing assets. Why would it need to check references? |
|
@dazinator Exactly. Even if the "incremental build" is negligible, that is still shipping a different set of compiled binaries than the ones that were tested, and in some environments that is unacceptable. |
|
I think we should add the --no-build. I encountered an issue internally where the build portion of publish overwrote binaries that were signed in the build output directory with unsigned copies. I worked around it with: <Target Name="PublishWithoutBuilding"
DependsOnTargets="PreventProjectReferencesFromBuilding;
ResolveReferences;
ComputeAndCopyFilesToPublishDirectory;
GeneratePublishDependencyFile;
GeneratePublishRuntimeConfigurationFile" />
<Target Name="PreventProjectReferencesFromBuilding">
<PropertyGroup>
<BuildProjectReferences>false</BuildProjectReferences>
</PropertyGroup>
</Target>which is the same as the real |
Strongly agree. Build is basically a composition of two operations: compile and deploy. Once I've compiled there is simply no need to re-compile when I want to deploy for a new platform. Compiling is just wasting CPU cycles and developer time at that point. |
|
I'll note, for the case where publish was overwriting binaries that had a separate post-build step applied: the incremental build is a perf optimization and shouldn't be relied on for semantic guarantees. so it should never be used as a solution to this problem. |
|
The PublishWithoutBuilding above won't be materially faster than an up-to-date incremental build (compile step would no-op but we still need to resolve references in both cases), so it is really more about semantics than speed. The fact that reference resolution can be slow is orthogonal and something that is being worked on. It will benefit both incremental builds and things that resolve but don't build. |
|
@nguerrera Not sure you can make that assertion without knowing the |
|
You mean read speed to determine what's up to date? |
|
@nguerrera Yes :) |
|
My assertion should have had more qualifications, but my main point was that you need the semantics of --no-build even more importantly than the speed. |
100% agree. |
|
Is it possible to approximate the semantics of --no-build by using publish earlier in the build process. I.e.
I can imagine this could be problematical for users who want to build lots of projects, but only publish some. (E.g. don't publish the unit test projects). Any other issues with it? BTW, even if this is workable, it still seems like a workaround. I agree with the @nguerrera and @jaredpar that the semantics of --no-build are desirable. |
|
@JohnRusk that works on small projects but not on bigger ones. Consider Roslyn which has ~160+ projects in our solution and eventually will have ~10-20 test projects that in theory need publishing. There is really no way to publish all of them without rebuilding their shared dependencies. Having an explicit, and supported, no build publish is the only reasonable solution here. |
|
We have a post build script in our dev environments which publishes our service and then restarts a docker container running in a VM which is hosting the service. Without the --no-build switch the post build step causes an infinite loop. I agree with bringing back the --no-build switch option - unless there is another way to achieve the above? |
|
Whatever the solution will be, it seems clear from the comments above that Build -> Test -> Publish is a highly desired workflow, for myself included. Thus, a publish command that can take pre-existing output is a highly desirable requirement, whether this is a --no-build flag or some equivalent. Even more so using a hosted build agent service where build time = money. |
|
My CI is based on Build, Test and finally publish those binaries that were tested. It made sure that the binaries that were tested were the ones published. Now when I publish, it rebuilds, giving me a brand new set of binaries... Please bring back that switch, it broke my CI. |
|
Just got here looking for this. Trying to run dotnet publish with visual studio open breaks hard. Using --no-build would work. Incremental build is still broken here for quite unobvious reasons. In answer to others above, --no-build should assume dotnet build finished and pick up the output binaries from that. |
|
Read through the above posts, and not clear as to what the holdup is. In my case it broke my CI step and I am now deploying manually. Can't --no-build be added back in so we can continue to work while the debate goes on? At the very least it should have been deprecated rather than removed, as it is a breaking change. |
|
Thanks all for the feedback. As I mentioned above, I'm in strong agreement on this. We will add --no-build in v2.1.0. |
|
Another use case (after the horse has bolted): We have a .NET Core solution with a number of docker containers with APIs. The solution also includes a developer-only console app for Dev investigation. When a Developer presses F5 and the whole solution builds and runs up docker, I want the console app (and only the console app) to republish itself to a Win 10 x64 target so that the devs can use the console app from Powershell. I would normally put publish in a post-build event in the I appreciate that my Devs can still do |
|
Same problem. Trying to automate publishing Asp.NET Core project. There is no way to force publish after build, so I ended up adding a 'dotnet publish' post-build event. Sadly it results in recursive builds that never end. A --no-build switch would fix something that I will now have to spend hours trying to work around. |
|
try |
|
Hey @gulbanana : thanks for the tip but for me msbuild still rebuilds dependent projects. So it's different than the former |
|
There's also the |
|
@dasMulli : thanks a lot! works great! (and I can finally publish my 5 projects without having to rebuild everything all the time :-) ) |
|
Here's how our build process used to look like with the 1.0.4 .NET Core SDK: As you can see, we use a /p msbuild option for With .NET Core 2, since the
I can fix this problem using Please add the --no-build option ;) |
dotnet publish rebuilds the binaries so we ended up with assemblies with default version. As `--no-build` switch is not available anymore I had to use a workaround. Issue is described here: https://github.com/dotnet/cli/issues/5331
|
Is there plans to add the no-build option back? Not building the references isn’t quite the same thing.. thanks! |
|
@diegohb At the top of this issue, you can see that it's slated for release with milestone 2.1.3xx. |
|
I will try to get to this soon. |
|
#2111 (in PR) implements the dotnet/sdk half of this. After that, we just need to wire --no-build to /p:NoBuild=true here. |
and others
Steps to reproduce
Dotnet publish -no-build
Expected behavior
It is supported
Actual behavior
No longer supported
Environment data
dotnet --infooutput:This is a useful switch. We would like to understand why it's removed and if there is a replacement.
The text was updated successfully, but these errors were encountered: