I have been going crazy trying to fix this publishing issue for days. I have a VSTO application for Office that builds using MSbuild.exe successfully, in both debug and release. The problem arises when I try to run MSbuild like such: MSBuild -t:publish. The funny thing is, when I use the publishing wizard in Visual Studio 2019 Community, my application publishes properly. I only have issues when trying to use MSBuild.exe with the publish target, not with normal builds.
By right-clicking my project in VS 2019 and clicking Publish, I see this wizard which produces the expected result.
Expected Result:
MSbuild produces a publish directory with a .vsto file for my application along with a a reference directory with dependencies and/or a setup.exe
The expected result of running MSbuild with the publish target.
Actual Result:
When running MSBuild -t:publish in a command line that is CD'ed to the directory of my project, I get this error:
Project "D:\repositories\myapp\myapp.sln" (1) is building "D:\repositories\myapp\myapp
.csproj" (2) on node 1 (Publish target(s)).
_DeploymentUnpublishable:
Skipping unpublishable project.
Things I tried:
I tried a lot of things to get this to work. I read these threads:
First thread : Applies to ASP.net applications not VSTO, also says that McAfee can cause issues. I disabled all antivirus on my machine, still no luck. I have tried adding properties such as: /p:DeployOnBuild=true /p:OutputPath="publish/" /p:PublishDir="publish" /p:VisualStudioVersion=16.11 (my version) and all combinations of these and it never worked. I tried using /t:Package but I get the error: error MSB4057: The target "Package" does not exist in the project.
Adding <OutputType>winexe</OutputType> to my .csproj does not work because this application produces a DLL on normal builds, not an executable.
Second thread
I already have this installed. I'm testing the command line publish on my local development machine before I try this on the build server.
Third thread I am not using a shared add-in.
Fourth Thread ITT and others, they recommend using a .pubxml but I cannot figure out how to make one of those, AFAIK they are generated by ASP.net applications and not applicable to a VSTO application. I could be wrong, but again I don't know how to create one properly.
Fifth Resource This is a lot of stuff to do, and I am confused if it will even work. I DO have VS 2019 installed, my program builds successfully and runs successfully, and even publishes successfully when using the publishing wizard. I am not using TFS. I am just trying to produce the VSTO via command line.
For anyone who runs into this problem, it is because you are not loading:
Microsoft.VisualStudio.Tools.Office.targets
I wish the log would have been more specific about that.
Related
I reviewed multiple responses from this platform about this new issue that I am experiencing and was wondering if there was a better way.
I created a Console application, utilizing DOTNET Framework 4.8 in the latest version of Visual Studio 2022. I conducted a Clean and rebuild of the Console App to create its EXE file. Then, I moved the generated EXE from the Release BIN folder to another folder on my Server for production. However, when I called and executed the EXE, I get an error that supporting DLLs were missing. I am using SendGrid to send emails from within the EXE and did install the Nuget Package to support the SendGrid functionalities.
In order for the EXE to work, I had to also drag all the generated DLLs from the release folder. This was never the case before.
How do I compile the EXE so it works as is into one single file?
Thank you for all of your answers and support. After reading all of them, the Publish recommendation is the winner. I was able to get just one exe file that I then transferred to my Server and it runs without issues on its own. I am not being asked to provide the SendGrid DLL or any other requests.
The pic below depicts my Publish Settings for net6.0. As a supporting document for this process, I also found the following article: https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file/overview
I have a C# Console application that was developed in different machines. In this application, we chose to use Fody, because it's the only thing we found that would embed all external resource dependencies (any extra class libraries) into a single executable for our application.
Environment Detsils:
Visual Studio Version: 16.9.2 (Professional 2019)
Type: Console application
Framework: .Net Framework 4.5
Fody Version: 4.2.1
Costura.Fody Version: 3.3.3
While this application worked without any issue in one machine, it starts giving trouble to another machine. We need to get this work on both machines as we need to cover lots of work. We have compared the two environments but couldn't figure out any difference.
the behavior of the issue is as below,
The first time when I clone and build a solution it goes in a
never-ending path and I have no other option other than end tasking
the visual studio.
And I observe that MSBUILD is occupied by something and I cannot end
task it
The second time when I start the solution and build it, I am getting
the following error.
Severity Code Description Project File Line Suppression State
Error CS2012 Cannot open '<<obj folder path>>\Debug\Binary.exe' for writing -- 'The
process cannot access the file '<<obj folder path>>\Debug\Binary.exe' because it is being
used by another process.' Binary.exe <<project path>>\CSC 1 Active
I had to restart the machine to remove the obj folder. And once it is removed Same above behavior repeats.
I found below a similar question below thread,
Error during building application with PropertyChanged.Fody
But it seems like this feature is obsolete in the latest Visual studio as per the below question.
Disabling Visual Studio hosting process on Visual Studio Community 2017
Further, I have tried to set the environment variable as explained in the below thread as I thought its somewhat relevant. However, it doesn't work as well.
https://github.com/Fody/Fody/issues/537
I must use these Nuget packages in my solution. Highly appreciate it if someone can share some thoughts to sort out this issue
I have created a C# 4.0 WinForms application using Visual Studio 2010 Premium SP1 on Windows 10.
Over the months I have modified and deployed this same App many times, using ClickOnce.
I have never had any difficulty until today.
I made one small modification to the code, which works successfully.
However, after building, and attempting to publish, 2-separate errors are thrown, as listed below.
#1) Cannot publish because a project failed to build.
#2) An error occurred while signing: The parameter is incorrect.
My application does contain a separate project, which is only a Splash Screen project.
If I go to Solution Explorer and attempt to build the 2nd project, it builds fine.
I have also tried to Build > Publish by using the menu in Solution Explorer, rather than from the Publish pane of VS.
Not only is it puzzling why a publish is failing suddenly now, but the error messages do not provide any clue as to where in the code a problem is arising, if indeed it's in the code.
Can anyone suggest how to correct this situation, as I am unable to publish my app any longer.
This error was puzzling, as I've used ClickOnce to deploy modified versions of my App many times. On a hunch, I decided to change the TimeStamp server from the following:
http://timestamp.globalsign.com/scripts/timstamp.dll
to this:
http://timestamp.globalsign.com/?signature=sha2
Since researching this error referenced the fact that Microsoft would no longer recognize SHA1, but needed the SHA2 cryptography, I tried using this latter server and after compiling, it allowed my app to do a successful publish.
If anyone else runs into this problem, the above solution may prove useful.
The problem starts with 'dotnet test' command. For some reason, the project with tests can't find a shared library that should be available for it (see a screenshot attached). As you may notice, I'm running the task via Azure DevOps using a custom agent (I think it doesn't really matter). From the logs I realized that the reason it works locally on my machine is that the project I'm talking about is being built in Debug mode in Visual Studio and this is exactly the folder the test project is looking for the library (i.e. \bin\Debug\netstandard2.0\my.dll).
The issue appears when I run 'dotnet test' as a task in the build pipeline in Azure DevOps and the process does not create Debug folder for this exactly project. It's weird, because 'dotnet test' builds solution once again (in the debug mode) and the folder should be generated.
I tried switching the project from 'netstandard2.0' to 'netcoreapp2.2' and adding xunit testing libraries. They're not required in this project but it has started producing Debug folder with compiled libs in it (i.e. \bin\Debug\netcoreapp2.2\my.dll). However, it didn't resolve the issue because the test project still looking for the lib in 'netstandard2.0' folder.
I expect the test projects will be relying on the libs available in Release directory (instead of Debug). Can't get how to achieve this.
You are referencing the DLL in the test project , instead add the reference of the project itself to it.
I have a Setup Project for my winforms application. After installing the application using the generated .msi i navigate to the installation folder and try to run the .exe file and nothing happens. I don't get an error or anything.
Steps i've tried to solve my problem.
Making sure the target platform x86 matches in the main project, setup project and every other project in the solution that the application has a dependency on.
In the setup project, made sure that i have a project output in the application folder that references the primary output from the main project. And that the dlls i use also are listed there.
Ran the application as administrator.
Activated Click Once security settings in the main project.
Ran sfc /scannow without finding any issues.
Restarted my computer.
When installing the program using the generated .msi on another computer i have the same issue.
When running the program from visual studion it works perfectly fine.
It is likely that your application is crashing because of some missing dependency.
Possible reasons:
A missing assembly (say, for eg, is all your third party dependencies present in the application folder after the installation ?)
Difference between .Net framework versions between your machine and the installed machine (say, for eg. 4.7 vs 4.7.2)
One useful tool that has helped us in the past is to use the Windows Event Viewer. If the program is indeed crashing, it is likely to have details about the reason for crash.
You can then use it as a starting point for further investigation.