ClickOnce Publish fails and can't clean up - visual-studio

I am using ClickOnce to publish my application to a virtual server. Sometimes (and we don't know why) the Publishing of the application freezes. It will copy some of the files and then about 20 min later will copy one more and so one. Other times it will work fine.
The problem I have is that when I click Project -> Cancel Build, it will stop the publishing process but it keeps locks on my Debug/app.publish folder. These locks are not released even when I restart Visual Studio. If I don't remove those locks (usually by rebooting my machine), and I try to do another normal compile/build, my whole Visual Studio freezes and hangs my whole machine as it gets stuck on those files locks.
Does anyone know why this would happen? Does anyone know how to remove the file locks on the app.publish folder so I don't have to reboot and get on with my work?

I have had issues where the files it's replacing on the web server get locked or are in use and difficult to overwrite remotely. I usually from time to time have to remote in to the server to delete them and then try to publish again. I've seen this on load balancing servers that replicate and the process has caused issues for me.

Related

Missing Data across shared computers

I have a setup where I have one computer at the office and another at my house, and the project data are being shared via OneDrive. This is purely for my own convenience and I only ever work on one computer at a time, shutting down Visual Studio when I'm not using it on either computer.
My current problem involves a project that is being synchronised via OneDrive but uses a SQL Server LocalDB database for development and testing but, despite the files being synchronised between the two computers, data that was inserted on one computer does not appear in queries run on the second computer.
Synchronisation only occurs once Visual Studio is shut down, since file locking prevents the process. I have verified that both the .mdf and the .ldf files are being copied (the file sizes and modification dates are correct). I have also physically copied the files via external harddrive to rule out the OneDrive synchronisation step, but the problem persists.
I have also verified that even after the files are copied, the inserted data is still present on the computer where the INSERT was done, but is not appearing when doing a SELECT on the second computer.
I was under the impression that LocalDB only used the .mdf and .ldf files, are there caching files somewhere else that I also need to synchronise?
All code and other project files are being synchronised just fine, it's only the database that is experiencing this problem.
I understand that this is probably a weird setup for most people, and I would never do this if I were in a team setting but I would appreciate some insight into what could be going wrong.
Sorry for the trouble to anyone, I seem to have solved the issue myself.
Just for pure sanity, I tried to detach and then re-attach the .mdf file on the second computer (the one that was not picking up the INSERTed data) and got an error about the LocalDB instance being a version too old for the file.
Turns out the computer on which the INSERTs were done was running a v13 instance and upgraded the .mdf file to that version, while the other computer was running a v11 instance. Both computers are now running on the same instance version and the missing data is now showing.

Clickonce App Doesn't start with Windows 1803

I have a Clickonce app from Visual Studio 2015 SP3 that is published to the network server and used in-house only. The program works just fine when launched from Visual Studio. It runs just fine on a Windows machine that does not have the 1803 update. But once a machine updates to 1803, the application no longer starts. I get the "Checking for updates..." window then nothing. On a fresh install, I usually get the Smartscreen telling me the program may be dangerous. It doesn't get that far.
I've created the Clickonce from a computer with the 1803 update and the problem still exists.
I've disconnected the machine from the network. The application starts but then has no database access and it needs the database. It's also written to hide buttons that would use the database to prevent users from trying to do things that require it.
I found a workaround (third paragraph) at https://social.technet.microsoft.com/Forums/en-US/7cbd16f5-526e-4b0b-a186-3ebf41b7b349/smartscreen-prompt-does-not-show-for-clickonce-app-since-windows-10-update-1803?forum=win10itprogeneral. When I start the application from the directory mentioned, I get the Smartscreen and can tell it to run anyway. Every time I click the desktop icon, it works just fine.
If a new release is published, the new release is downloaded and the program updated, but the Smartscreen no longer appears and the application never starts.
So somewhere between installing the latest update and the Smartscreen, this is failing. Anyone else experiencing this and have an idea as to why?
Yes, frustratingly I also experienced this today. Presumably a security update that they'll release another patch for given this is quite a pain for developers and users of small business apps.
Rather than disable Defender or SmartScreen I chose to add my deployment website to the Trusted Sites in Internet Explorer and that then re-instated the warning dialog and my app updated and ran as before.
Really annoying given the nature of the issue and how long it took to figure out, but at the same time I had to use IE today, which is a rare event nowadays.
This works for me...Warn doesnt warn anymore...
After running in the same problem, I just found that my application was going to halt after a stupid uncaught exception.
Despite the fact that the image below is in Portuguese, Event Viewer shows the right error cause.
In my case, was a corrupted settings file!
It appears as though some subsequent Windows Updates have fixed the issue on several of our PC's that were previously experiencing the issue.
Check for the updates listed here.
https://www.catalog.update.microsoft.com/Search.aspx?q=KB4338548
Running winver.exe will show you which build you have.

Microsoft.VisualStudio.Web.Host.exe taking over

My solution consists of a 195 (not a typo) C# MVC application projects w/ some ASPX pages as well running on VS2017 on Windows 10. Its nothing bleeding edge. A days ago, "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Microsoft.VisualStudio.Web.Host.exe" started taking over my machine.
Here is what I have experienced.
The app (Microsoft.VisualStudio.Web.Host.exe) will keep VS2017 from loading a solution I'm trying to open.
The only fix is to kill the offending exe via Task Manager.
The app will keep VS2017 from exiting when a solution I'm using is open.
The only fix is to kill the offending exe via Task Manager.
When trying to build, things slow to a grind.
The only fix is to kill the offending exe via Task Manager.
The offending app will use as many resources as possible.
I've done Win10 an Symantec virus scans on the offender. Both scans came back negative.
I've tried adjusting the app's settings in task manager so that only one or two cores can be used by the process. This helps, but sometimes I still have to kill the app to get things working in VS2017.
Whenever I kill the app, it comes back within 30 seconds.
Sometimes, things work fine. No discernible reason why.
iisreset does nothing.
I resorted to renaming the EXE file, that way it couldn't attack me again.
That seems to work, but its a hack.
Does anyone know what the root cause is, and how to resolve it?

The specified task executable cmd.exe could not be run. The process cannot access the file because it is being used by another process

I recently started getting this error intermittently when running or building a solution in Visual Studio 2010:
The specified task executable cmd.exe could not be run. The process cannot access the file 'c:\temp\etc' because it is being used by another process.
There are similar problems reported elsewhere, due to things like two projects building to the same folder, or anti-virus issues, but none of them are the problem in this case. I've reduced the solution to a single project and it still happens.
It turns out that the problem was a service my employer recently installed, called AppSense Application Manager Agent, which is designed to limit my access to admin-type features on the PC.
Luckily I still have access to the services control panel, and disabling the service fixed the problem.

Hosting Visual Studio projects in dropbox

I develop both on my desktop and laptop, and I am frequently switching between them. Are there any problems that could arise from keeping a project folder in my dropbox and always accessing/editing from there? I'm running the VS2010 on both, but W7 on one and W8 on the other.
I'm using it often. But I do experience some issues. It seems that sometime VS and Dropbox conflict. This shows by leaving some temporary source files or by errors during compilation of file being locked.
In fact I came here while looking how to solve them. But still they are only a little issue and I keep using it that way for a long time.
EDIT: It is not just me. See Visual studio 2012 and dropbox don't play nice together question on SuperUser.
I'm using Dropbox to host my project and I edit and build directly on there and have experienced no problems, ever. Win7, VS2010, CPP. I find Dropbox to be simpler and equally robust to than version control software. I'm a big fan. I should say Microsoft OneDrive once failed me, horribly, and I no longer trust it. With Dropbox, I always check the icon in the systray carefully to make sure it is finished updating before I turn my computer off.
I use both git and Dropbox, as I also switch which machine I'm working on. This way I can use source control with the rest of my team, while also able to pick up where I left off. My 2 PCs that sync are my one at work and at home. Both desktops, both almost always on and running dropbox.
Rarely I get conflicts, when a machine is offline or something. The solution 99% of the time is to simply delete any conflicting files. Because I'm constantly up to date with git, it's fine if I ever have to delete all my local code, since I can always get it back.
So it's really for nothing other than being able to run out of work on an urgent task, and then resume where I left off when I got home.

Resources