I'm working on an ASP.NET Web Forms application (.NET 4.0 VS 2010). Lately we've been experiencing problems which have halted our release process.
Specifically, we have found ourselves unable to publish our website (to precompile it). Across all of our developer environments (3 developers), the build process appears to be stalling/hanging - without any report of error. Sometimes, it appears to succeed but only a couple of the compiled DLL's and .compiled files appear (less than 10 out of ~350 files).
I've loaded in various revisions of our projects from our source repository, both latest and very old versions which previously worked. The fact that it's happening across developer environments suggested that the problem was due to some change we committed, but the fact that the problem is occurring across latest and old revisions of the application perhaps suggest otherwise.
Internet searches for this issue reveal nothing significant. Things I've tried include the following:
Building and rebuilding
Clean solution
Deleting the .suo files for the solution
Deleting the contents of the ASP.NET Temporary Files solution and deleting the target location folder prior to publishing
Tried selecting the 'Allow this precompiled site to be updateable' option (produces an object reference error without a file or line number)
Restarting Visual Studio and PC
On examination of CPU usage during the build, the CPU usage for the devenv.exe process is in the sub 0.10% area for most of it (a few spikes at the beginning just).
I appreciate any assistance anyone can provide with this
UPDATE: We have found that eventually, the publish succeeds, but sometimes we get a long series of failures before it succeeds. There's no consistency at all... it seems random.
I had this same issue with Visual Studio 2015 on Server 2016. The issue was partially resolved by running VS as administrator. However the apparent root cause was virus scan - in this case ESET- installed not as a File Security but as workstation. This I discovered when every entry of the license codes for ESET appeared to work - then ESET reported it still required verification. Uninstalled the badly chosen ESET and reinstalled the correct license product and, presto, with or without pre-completion, the publish works! Thanks to the previous virus scan tip!
The issue seems to have been caused by the McAfee virus-scanning software that we have installed.
Only with admin privileges, we were able to temporarily disable the real-time scanning, and as soon as we done that the ASP.NET Publish would complete successfully almost instantly.
For anyone else in this situation, it was McAfee's anti-virus software that was causing the problem. I checked the logs for the anti-virus software and there was no evidence that the software was blocking anything related to the Visual Studio processes or the folders that are manipulated during the build and publish processes (e.g. The ASP.NET temporary files folder).
Specifically, the csc.exe (C# compiler) and devenv.exe (Visual Studio) processes were having problems with McAfee. These processes were added as 'Low-Risk Processes' to the 'On-Access Scanner' to resolve the problem.
McAffee removes any changes to it's settings every 15 minutes, meaning that the action of adding these processes to the McAfee exception list (low-risk processes) has to be repeated every 15 minutes when you are building your code. This could happen a lot during a working day.
I see you do not have Allow this precompiled site to be updatable checked, so your Publish may be attempting to update what it thinks has changed.
Try deleting all the files (copy existing files to a new location or rename the folder, if you want), and try your Publish again.
Related
I recently bought a new computer. After getting everything setup, I installed visual studio community 2019 and gitkraken and cloned down my project(which was building and running fine prior to changing computers) and I'm running into an issue. It's a game dev project using MonoGame.
These are the errors that I'm receiving currently. I've tried multiple versions of MonoGame including 3.0, 3.5, and 3.7. I've attempted to reinstall redistributables, I've cloned into multiple directories, I've attempted building a different project(a fork of the same project that I've worked on more recently on my previous pc). I have a friend that works on the project with me, he was able to clone into a new directory and build immediately. I've attempted building the content package in the MGCB manually and am also running into an issue where it's not finding a specific font file(that i've verified is installed on my computer, and also tried dropping in the correct directory for building, but have had no luck there. However, I feel like this is a separate issue, but it may provide some insight to someone who is more experienced than I.)
Ideally, this project should clone down and build just fine on a fresh install. It always has before, but there's something going on here that I'm not sure about. I've tried several different things and have hit a wall. There isn't much online about this specific issue that I've seen, so if anyone has any ideas I'm all ears. Thanks.
I figured out the issue. It was something simple as usual, a product of my own stupidity. When I first downloaded the font, I extracted and right click > install. So the font was installed on the PC. I spent a couple days on this issue, and at some point when trying to reinstall the font there was a new option that hadn't been there before called 'Install for all users' with the shield icon next to it. Previously, I'd only had the option to 'Install' without the shield icon. Not sure exactly what the difference is between these two options showing up, but once I clicked 'Install for all users', the issue was solved. So I guess initially the font was only installed for my specific user account. I'm not sure why this is an issue or why the option to install for everyone wasn't available previously, but this is what solved the problem.
Change the Build Action on the "Content-> Content.mgcb" file to "none" or "ignore"(I can't remember which). This will allow the game to build successfully.
Here is a temporary work around to allow you to continue development:
If the XNB files are not properly building in the Pipeline tool, you can copy them(from an older build or compile them on another machine) into the output directory, Content directory under the directory containing the .exe file, manually.
I'm using the Visual Studio Installer Projects extension to build the MSI-installer for my application. However, my application is meant to be running at all times, and if it's open when the user is installing a new version of my software, the open files are not overwritten, and very little to nothing is actually updated (although there are no installer-errors).
I've found that using the installer project's "Custom Actions" to run a script that closes the application doesn't help, as none of the actions are called before the files are replaced.
Is there a good way to make sure the open/locked files gets terminated before the files are supposed to be overwritten?
We had this problem, and the solution we came up with was to create two apps; the user app and an updater app. The MSI installs both. Each app checks if the other needs updating and, if it does, closes the other app, downloads the other app's updater, runs it, then relaunches the other app. Additionally, each app monitors if the other app is running and, if it isn't, launches it.
It would be useful to know more about your application and how you are doing the upgrade because:
You will normally see a FilesInUse dialog saying that files are in use, prompting the user to shut them down, but not if the install is silent.
Visual Studio setups have no built-in support for shutting down and restarting services, so if your app is a service you'll need extra work.
Files that actually do need to be replaced will prompt the user for a reboot (if they are not previously shut down) in order to replace them at reboot time.
So if you're not seeing reboot requests or FilesInUse dialogs in a UI install then something else is going on. So you need to be sure that:
a. You are really doing an upgrade where the version of the setup project has been incremented, the UpgradeCode is the same (and the ProductCode changes when you increment the setup project's version). Your symptoms could be the result of the upgrade not working and you're seeing just a repair.
b. The definition of "new version" is that you have an upgrade as in a., AND, the file versions of the binaries have been incremented. The default overwrite rules for installs require incremented file versions, so if they haven't been incremented you'll see no updates, and Windows will not attempt to show FilesInUse dialogs or reboot because there are no files that need replacing.
This isn't a solution to the problem, but rather another solution; the one requiring the least work in the end.
I ended up not using 'Visual Studio Installer Projects' for my installer. Instead I looked to Advanced Installer, which just works with no issues. Things like this is taken into account, and custom actions allow for more options.
If your project is open source, you can write to them about a free open source "professional" license, equal to their "professional" plan, which is normally $399 (onetime purchase).
REBOOT: How are you installing this MSI? What command line? If you set REBOOT=ReallySuppress on the command line, you will not be prompted for a reboot even if one is required to complete the installation of the product.
msiexec.exe /i MySetup.msi /QN REBOOT=ReallySuppress
If you are using a distribution system I suppose suppressing reboot prompts could be standard behavior. Then your product files should be put in place after a reboot (PendingFileRenameOperations or perhaps some newer mechanism).
It is also possible that Visual Studio Installer Projects do something strange that I am not aware of.
Log: I would try to create a good log file for the install, to determine what is going on:
msiexec.exe /i C:\Path\Your.msi /L*v C:\Your.log
Log All MSIs: Personally I like to enable logging for all MSI installations - as described in the "Globally for all setups on a machine" section in the above link.
Interpreting an MSI log: interpreting a log file can be challenging sometimes. Here is an answer with some links to help with this.
Reboot Manager: Reboot management is a very complex topic, and Windows features functionality - in the form of the restart manager feature - to try to minimize the need for reboots, by instead shutting down and restarting applications as part of an installation in an "auto-magical" fashion (application listens for messages and shuts itself down gracefully when told to, and the system may restart the application after the install - if configured to do so).
Updating your application to comply with the restart manager is the only real fix for such problems that you see, in my opinon.
The section "Restart Manager" in this question tries to summarize how to implement such support (maybe just read the yellow section a bit down the page).
The Advanced Installer guys have a very nice, technical article about this:
How do I add support for Windows Restart Manager to my application? Also linked to in the link directly above - still worth a direct link here I think.
According to below link
https://social.msdn.microsoft.com/Forums/windows/en-US/0b40b367-3341-43d8-b82e-1ace546969f8/how-can-installation-stop-and-restart-existing-service-?forum=winformssetup
"There is no good support in VS installs to stop and start services. During install, the issue is that custom actions run after everything is installed so it's too late to stop a service that you are upgrading or replacing. Yes, they have names like "BeforeInstall" but they really are not before the install."
I've upgraded my Windows to 10.0.16299 (latest) and my Visual Studio to 15.5.1 (latest). Since then, I am seeing this error message when I clean or build my Xamarin solution containing an Android project:
obj\Debug\android\src\android\support\customtabs\CustomTabsClient_CustomTabsCallbackImpl.java:4:
error: error while writing CustomTabsClient_CustomTabsCallbackImpl:
obj\Debug\android\bin\classes\android\support\customtabs\CustomTabsClient_CustomTabsCallbackImpl.class
(The process cannot access the file because it is being used by
another process)
I figured that the locking process is Visual Studio itself after I tried to run and debug the app.
The issue appears no matter whether I want to run the app on an emulator or a connected real device.
There's lots of advice what to do when a process locks a file including SO such as the famous the process cannot access the file because it is being used by another process. However, all provided answers don't help as Visual Studio itself locks the file and the only workable workaround is to restart Visual Studio - that's not a solution.
What is causing this file to be locked? Any idea? Any advice?
Sometimes it helps to kill the MsBuild.exe. Also, you could find other solutions such as described here: Xamarin Android project cannot build....
Basically, it seems to be a problem with Studio 2017 Version 15.5. It will be fixed with the next versions probably.
Darn it, my suggestions won't fit in the context of a comment, so here goes:
Sounds like the process being debugged, or the emulator hosting the debugged process, itself, has not fully closed down, and is in a hung or semi-hung state. Have you checked the process manager to see if this is the case? You may want to to try adding Environment.Exit() to see if this helps come back to a good state.
Another thing to check is, whether your access levels are the same between the two machines. Check not only the PC, but also at the emulator as well. Check everything, and ensure the access levels/modes are identical.
Finally, try running VS 2017 in administrator mode, and see if the problem persists. It's entirely possible that the level of access that you used to run pre-Windows 10 is different in the Win10 world that you live in, now.
During our adventures of building a 'simple' API using WebAPI we've had our fair share of issues as any project does, however I am unable to find any such resource that can explain the following behavior:
Details :
Visual Studio 2013 with Update 2 (however, before updating, this was the same)
Windows Server 2008 R2
Web API 5.1.2
The issue seems to be related to the "Publish" command, specifically the "Precompile" option.
When running via IIS Express, we see no issues at all.
If we publish once, it fails to include the App_Global.asax.compiled & App_Global.asax.dll in the bin directory. If it is updating an existing instance of the application, it will actually delete the existing two files.
Note: This Happens regardless of WebPublish or FileSystem Publish
This behavior is causing 404.0 Errors upon loading to IIS, instead of our expected 201.
However, if I publish a second time no changes to the previous profile/configuration, it adds the two back.
For a while, we thought it was permissions issues, and weren't seeing consistent behavior. This happens on all of our development machines with the same behavior.
We've seen posts regarding mysterious behavior, but from our analysis, this is the root of the problem.
Just wanted to let everyone know that my problem was solved.
This was an issue with a virus scanner scanning the newly created temp directory for precompiling and actually locking the files in question.
So if anyone has issues such as this and is running any antivirus (especially enterprise level):
TLDR:
Check if your antivirus is locking files.
Turn off all compsec scanning utilities and turn on one by one to isolate which is causing problems.
I have developed a windows application on C# in Visual Studio Express 2010. Now I want to deploy it.
I used publish to deploy but when I run the project it get error on the form where I have used some external files which I am using for I/O operation, read and write files.
How do I resolve this error? I am also using one folder for files.
I'm a big fan of using WiX for installers - even if you've got Visual Studio Pro with the built in MSI creation tools
http://wix.sourceforge.net/
the benefit of WiX is that you can do most anything, from the super simple to very complicated. The tool is great b/c you can get started quickly and then move up (adding dialogs, etc) as your app gets more popular.
One trick for installers - consider using VMWare/HyperV, install a test OS then take a snapshot of the OS before you install your app. IF everything works, great - you're done. However if something isnt right, roll the OS back to the pre-install snapshot, fix the bug, and try it again.
Add those external files to the project
Right Click the external files in your VS Set the Build Action as Content
Copy to Output directory to CopyAlways
Then try deploying
That may be due Windows 7 UAC permissions. Despite the fact that current books, msdn and even the snippets in Visual Studio teach methods of file IO, most are not correct when taking UAC into consideration.
All of your file operations should take place in UAC safe zones such as
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
You cannot read or write to files in the C:\Program Files (x86) directories unless you have elevated your app to run with higher privileges.
If you install your application and right click the executable and select Run As Administrator and everything works the problem is UAC.
If you haven't coded around UAC limitations I highly recommend reading up on it. It will save many headaches down the road.
http://www.codeproject.com/Articles/17968/Making-Your-Application-UAC-Aware