Resolved Publish failed. Check output for more details.

chairmanPC

Active member
Joined
Apr 19, 2021
Messages
38
Programming Experience
10+
I worked on my project on another computer. When I transferred it to my work laptop to continue working on it with a USB Drive, it built fine.

But when I tried to publish it to my Documents folder, I get the error message below:
1625716581113.png


How can I fix this issue? I am stuck here! Thanks for any help!

Here is the dump file:
8/7/2021 12:03:02 pm
System.AggregateException: One or more errors occurred. ---> Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.
--- End of inner exception stack trace ---
---> (Inner Exception #0) Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. <---

Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.


===================
It's a Winform project., and the project built and published totally fine on my first machine. Is this information enough? I never really mentioned anything about "public" here.
 
Last edited:
Solution
Guys, I've solved the problem.

It seems that I did not set the framework to .NET 4.8 before publishing the project on my work computer, thus triggering the publish error. Just set the target framework with a click of a button in the publish area, and you are good.
There's really no information there to work with, so providing a solution would be utter guesswork at the moment.

The first thing is, what does "transferred" actually mean? This is a perfect example of why even hobbyists should be using cloud-based source control. Along with various other benefits, it would allow you to sync your code and any changes to it across multiple machines. If you mess something else, you simply revert or pull the data again.

Also, it would help if you provided as much information as you are able. For one thing, you haven't told us what type of application this is, so we don't even know what "publish" actually means. Also, you haven't described the specifics of the publish, e.g. are you trying to publish to a location that is inaccessible on the second machine? You also haven't indicated whether things still work on the first machine. If an issue is machine-specific then that's a significant clue.
 
Last edited:
There's really no information there to work with, so providing a solution would be utter guesswork at the moment.

The first thing is, what does "transferred" actually mean? This is a perfect example of why even hobbyists should be using cloud-based source control. Along with various other benefits, it would allow you to sync your code and any changes to it across multiple machines. If you mess something else, you simply revert or pull the data again.

Also, it would help if you provided as much information as you are able. For one thing, you haven't told us what type of application this is, so we don't even know what "public" actually means. Also, you haven't described the specifics of the publish, e.g. are you trying to publish to a location that is inaccessible on the second machine? You also haven't indicated whether things still work on the first machine. If an issue is machine-specific then that's a significant clue.
Ok, I am working on a Winform project. And I used a USB drive to move my project from one computer to another. I only want to publish the project to my Documents folder, and the project built and published totally fine on my first machine. Is this information enough? I never really mentioned anything about "public" here.
 
I never really mentioned anything about "public" here.
That should have been "publish". Publishing a project means different things depending on the type of the project.

And no, it isn't really enough to provide a solution. This is where you need to be a developer and do some actual testing. If you copy the project back to the first machine (probably in a different location) then does the publish work or not? Can you create a new project on the other machine and publish it successfully? This will indicate whether the issue is specific to the machine, the project or the combination of both. What exactly did you copy across? We don't know that you didn't miss something important. Can you create a new copy and publish that on the other machine? What are the settings on the Publish page of the project properties? When you have so little information to go on, you need to do some proper testing to see what works and what doesn't and then work out what's different between the two.
 
I was serious about the source control too. You really ought to stop what you're doing and set up a DevOps account or the like and then push your source from the first machine and pull it on the second. That will reduce the likelihood that you will make a mistake or that corruption somewhere will create an issue.
 
I was serious about the source control too. You really ought to stop what you're doing and set up a DevOps account or the like and then push your source from the first machine and pull it on the second. That will reduce the likelihood that you will make a mistake or that corruption somewhere will create an issue.
Thanks. I will do that.
 
Using Microsoft.WebTools in a forms application?

On the drive with your project, open it in visual studio and click build, and clean. Then rebuild your project for 'release'.
If that doesn't work, run the application in debug mode on the computer where it won't run and then you will see where it is failing.
Does the diagnostic log tell you anything additional about the error?

@jmcilhinney don't those errors only come from click once applications? (Where they tell you to check the logs in your temp folder)
 
I've been pondering why Microsoft.WebTools was in there, but I think that's what is used to update your clickonce. Sadly your error appears to be a widespread open bug from what I have read here : System.Exception: Publish has encountered an error · Issue #10621 · dotnet/sdk and on the VisualStudio forums. You are far from being the only reporting this exact error. And while this might be far from your issue, can you check this answer and make sure this is not in your assemblies : Microsoft.Net.Compilers
Reference for proposed fix : 'Publish failed' but build succeeded? and let us know if that worked for you?

Sorry running on no sleep, so not on top of my game today. I also forgot to link you these :
and :

And for some additional light reading on why you probably won't want to use clickonce anyway :

The two first links will tell you how to disable it. From there you are better to simply build a release version of your app without the publishing features. The comments on those top solutions on both stackoverflow links also mention tools you can use for installer options, ie installshield, although there are other free alternatives if you look around.

Sidenote
If you stick with clickonce - read your error logs, because if memory serves me right, the logs are actually useful in clickonce apps, and I believe they also tell you the method where the error occurred. There also should be another folder at that tmp location with another log inside it. If it contains additional error logs, can you share them?
 
Rather than mark a topic as resolved without a reply, could you please explain what worked for you?

As this information may help others.
 
Guys, I've solved the problem.

It seems that I did not set the framework to .NET 4.8 before publishing the project on my work computer, thus triggering the publish error. Just set the target framework with a click of a button in the publish area, and you are good.
 
Solution
That would indicate that your process of transferring your project from one computer to another has some gaps in it because the target framework should be in the files associated with your project. Again the recommendation above about using source control would have rescued you if you had let Visual Studio determine what files to add to source control.
 
Yeah, you may have solved this immediate problem like that but who knows what other issues are lurking? If the target Framework didn't come across in your "copy" then what else didn't? If you had simply copied the solution folder then there's zero reason that the target Framework shouldn't have been maintained so what else might be different on the second machine?
 
Always check the output window for the actual error message, sometimes, it's due to wrong password if your are deploying to a host server on the internet, low or no internet connectivity , sometimes low storage space on your computer
 
Back
Top Bottom