VS2017 publish causes error on startup "cannot load file or assembly ..." Running directly from the build works but not from the deployment in app.publish folder. The error shows even on my development computer. However, opening the same solution in VS2010 and publishing from there, all works as expected. I cannot find this same issue on the web.
After searching for all things Click Once, I came across an answer for a different issue and tried it. I upgraded the target framework to .NET Framework 4.6.1 and updated the NuGet Packages. Afterward, I was able to publish and run the Click Once Application with no errors.
Related
Just setup new surface pro. Moved from Laptop. I installed VS 2017 (even tried 2019) and loaded project from old laptop. Made changes and went to Publish new install and getting 'The publish components are not available. You need to reinstall Visual Studio to publish your application.' under publish tab. Program will build and can run the application from IDE.
Had to save project and publish using old laptop. I searched the internet and seen many posts about this issue but no solutions.
I have uninstalled VS 2017 and reinstalled. Have tried community version and pro version and same issue.
Hopefully someone has seen this and actually found a way to correct issue.
I noticed that my old laptop also had visual studio 2015 installed. I went ahead and installed that on new surface and now the ability to publish is available in vs 2017
I created a clean Web API .NET Core project and published it, using the default settings, to an Azure App Service, also created using all the defaults. Then I started up Visual Studio 2017 in Administrator mode and tried to attach the debugger. I got:
Unable to find a process called dotnet with arguments
.\MyCompany.WebApi.dll. The process may still be
starting, please try again.
What is wrong? Has anyone successfully debugged a App Service with .Net Core remotely. Seems like kind of a limitation of the environment if not.
EDIT: I upgraded to Visual Studio 2019 and was able to remotely debug processes running in Azure. There seems to be a critical failure with 2017 and Microsoft can't support it.
Today I suddenly started getting errors when I try to run/debug my Azure cloud project from Visual Studio. I'm running Visual Studio version 15.7.3 and Azure SDK version 2.9.6. The error message says:
Failed to debug the Microsoft Azure Cloud Service project. The output
directory '\csx\Debug' does not exist.
Yesterday it worked fine, but during the night Windows Update installed some updates and rebooted my machine.
I have tried the following things without success:
Created the folder myself
Set full permissions for everyone on the csx folder
Set full permissions for everyone on the parent folder to the csx folder
Uninstalled one of the updates which was installed during the night
The strange thing is that if msbuild creates the csx folder without problems, using this command:
C:\src\services2>msbuild <cloudproject>.ccproj /p:configuration=debug /maxcpucount /p:outdir="c:\OutDir" /p:overwritereadonlyfiles=true /p:targetprofile="Cloud" /target:Clean;Publish
Any suggestions on how to fix this problem?
After struggling with this problem for a long time, I concluded that it was a problem with Visual Studio, since msbuild worked without problems.
After running a "Repair" on Visual Studio, it now works again :-)
You run the repair by selecting Visual Studio from Settings/Apps & features and clicking "Modify":
In the Visual Studio installer, you then select "Repair":
I have set up a CI server for our .NET projects. To build those projects I want to use the Visual Studio executable devenv.exe.
This worked out perfectly during the "evaluation period". Now these 30 days are over, to keep using Visual Studio on my Desktop computer, I just updated my license with one mouseclick. Doing this on the server allows me to build using the GUI, but when running devenv.exe programatically with the required parameters, I am receiving an error that the evaluation license expired, even though I renewed it.
I have already tried a clean reinstall, which did not fix the issue for me. Visual Studio on the server is connected to the same account I am successfully using on my Desktop PC.
Is there a known fix for this issue?
Figured it out. The license is somehow related to the user that launches Visual Studio. So to to automatically build projects with devenv.exe, the building agent has to run under the same user account, that installed an launched Visual Studio.
I have an outlook 2010 add-in that has a service reference to a simple web service we have set up.
The config for the service is in the app.config file.
This add-in is deployed using windows installer into the program files folder.
This has been working without a problem until yesterday.
Yesterday I installed VS 2010 SP1 and now when the add-in tries to access the web service it has the error "Could not find default endpoint element that references contract in the ServiceModel client configuration section."
Does anyone know what has changed and what is causing this problem?
If I open the project in VS, build and then run from within VS the config is picked up fine.
Thanks
Gavin
The actual solution is more simple. There was a breaking change made to VSTO 4 sp1 in that the manifest has to be a fully qualified URI. So when building your setup project, you must prefix the path to the manifest with file:/// and everything works as you'd expect again. They didn't get the documentation and tutorial pages updated in time for the release. I'm not sure that they have been yet.
Perhaps you're hitting a problem with extensionless services after installing SP1? http://support.microsoft.com/kb/2468871 - Issue 16?
I had this exact same problem. After installing Visual Studio sp1 (which installs VSTO 4 sp1), my Outlook addin could no longer find its config file for service endpoints. The only solution I've found so far is to run the VSTO setup (the new one) and choose uninstall, then run the old version that was previously installed and rebuild the setup package. If the new version is installed on the client machine, that machine will have this issue. Your setup may not detect it because typically you specify a minimum version for it to look for. I haven't found any other info about others having this problem besides yourself or anything official from MS about the problem.