Im currently suffering with extrem slow buildprocess on my local machine.
It takes very long time when msbuild comes to "Processing resource file".
Long means, about 10 to 20 seconds per resx-file.
Those resx-files aren't big, acctually the most of them are empty and are just there because of old winform Projects.
Does anyone have any idea what i could investigate?
What i already did:
Im running VS with administrator privileges
All folders of VS and my Solution are excluded in Windows Defender
im running a private, tfs server workspace
restartet my pc :)
thanks for any advices/suggestions in advance
if more information is needed in any way, just ask :)
Problem was, yesterday i was investigating a bug report from a customer, with some IOException, while getting a temp file name with GetTempFileName. So i generated 65535 temporary files with GetTempFileName, because this is a documented limitation of this method (2 ^ 16 - 1 possible files), to reproduce this behaviour and simply forgot to clean up %temp% after investigation. and this msbuild behaviour was the result of a %temp% folder full of tmpXXXX.tmp files
Related
Am trying to publish my Web Application. It worked fine literally 15 minutes ago and not aware of anything changing in the meantime. Now receiving this error:
Copying file bin\myApp.dll to obj\Release\Package\PackageTmp\bin\myApp.dll failed. Could not find a part of the path 'obj\Release\Package\PackageTmp\bin\myApp.dll'.
Tried copying the dll manually and Windows just hangs.
Any ideas?
Usually this happens to me when a file is locked (still in use) by windows.
Try right clicking on the solution and doing "clean" solution. Then rebuilding.
If that does not work. Try cleaning solution, closing Visual Studio, re-opening it, then publishing it.
Think I've fixed it. Had to remote directly into the server and cut the release folder to the desktop then copy it back again. Window's threw some permission errors, which it shouldn't have as I have full permissions but worked when I clicked "Try Again". Then manually inserted the dll the same way and tried publishing again. This time it worked. Bit of a weird one but seems to be working now.
I was looking for a solution to this problem and I've found out, in my case, that the folder was not being created when the project was published in IIS. So I've copied the folder from my project's directory to the location where the project is published.
It worked for me!
I had a similar issue and found that the cause was the permission set in the Build folder located in the project folder where the software is compiled to.
For some reason the permission were not set to full, and on further investigation the delete permissions were not set to active.
This meant that the first compile succeeded, but the second failed because the original folder could not be cleared by Visual Studio, or the original files could not be overwritten.
Setting the permissions to full fixed this issue.
This happened to me when you have a files that the path that is longer than 255 chars.
Ensuring all file paths from the drive root to all the files in the Debug\Package\PackageTmp folder were shorter than 255 corrected the issue for me
when saving a source file e.g. .cs I often get the following
Click Save, Save all or build (any action that triggers a save)
VS prompts with a "Save As" dialog
selecting the same filename as the original often fails with "Cannot create a file when that file already exists"
Waiting up to 30 seconds in the "Save As" phase normally results in success.
Things I've tried so far
disable Anti-virus - no effect
switch from local workspace (we use TFVC) to server workspace - problem goes away
modify the same files outside of VS - works without issue using Notepad / notepad ++
Disabling all addins / extension - no effect
Deleting workspace and recreating - problem less common initially then back to common
same source code for a dev that has not seen the issue - they don't see the issue
Running VS on a VM rather than our normal Workstations - same issue
upgrade TFS from 2013 to 2015 - same issue
Size of the workspace does not appear related. Have seen the issue with small and large (>100k files)
These imply that the problem is workstation or user related. Not related to source control. something to do with Visual studio
other info
we don't use drive encryption
source code drive is RAID 1 ssd
VS saves files by creating a new temp file in the same directory then renaming it. By monitoring the file system, i can see the temp file being created so it looks like the rename throwing the error.
there was a similar issue in MS connect which is marked as fixed:
https://connect.microsoft.com/VisualStudio/feedback/details/860265/unable-to-save-files-in-vs-2013-update-2-rc2
The error messages mentioned in the issue above appear to be different though, create an existing file vs process is using file
This is affecting about 15 of 40 devs and the workaround is fairly distracting. We have workarounds but would be good to know the cause
Found the cause of this - a security product called Avecto. Looks like an update that was deployed around January.
Removing Avecto makes the problem go away as a workaround. Just disabling the Defendpoint service is not enough, it must be fully uninstalled. Infra will no doubt raise a bug with our vendor.
It only affects files that live on an ssd, could not repro for files on hdd which is why not everyone was affected
Updated 2016-04-25: Avecto have a fix for this. I'm not aware of the details (managed by another team) but we haven't had an issue since applying it.
I am developing a VB.NET (4.5 framework) solution in Visual Studio 2015, Win10 OS, and have been able to run the builds uninhibited for several months, but now I am receiving the following error upon starting the build:
vbc : error BC2012: can't open
'C:\MyProject\ProjR5\ProjR5\obj\Debug\ProjR5.exe' for writing: Access
to the path 'C:\MyProj\ProjR5\ProjR5\obj\Debug\GenTagR5.exe' is
denied.
At first, VS2015 would give me the option to run the last successful build, but even that is no longer an option. After exhaustive internet searches on this problem, none of the dozen or so given solutions are solving my issue.
Here is what I have tried in order to resolve the error so far:
Ran sfc /scannow (elevated prompt)
Using ProcessExplorer, find handle or DLL substring that included my project
Made sure there were no hanging procs (including procs with my project name, devenv.exe, [project].exe, [myproject].vhost.exe, etc.)
Restarted VS2015
Restarted VS2015, running "as Administrator"
Restarted Computer
Full Shutdown of computer
Complete Rebuild of Solution
Build->Clean Solution
Build->Clean Solution, then Build->Build Solution
Build->Rebuild Solution
Uninstalled and Reinstalled VS2015
Disabled all indexing
Removed "Read Only" attribute from entire project folder and files within
Checked startup scripts for like- or identical processes
Disabled all AV apps
Disabled all antispyware apps
Disabled all firewalls
Verified that Application Experience (services.msc) wasn't disabled (I'm using
Win10 ... it isn't even in the list of services)
Set Tools->Options->Projects and Solutions->Build and Run->Max. parallel
builds to 1
Rerun aspnet_regiis.exe (under .NET\Framework)
Checked Local Security Policies and verified account was listed under
"Impersonate a client after authentication"
Removed \bin and \obj folders
Put \bin and \obj back when removing them didn't help
Removed \bin and \obj folders, then Rebuilt
None of these have worked. Any suggestions?
The problem ended up being Samsung Magician's Rapid Mode losing data during its write-caching phase to my solid state drive. I turned off Rapid Mode, and now the project builds without any problems.
Sorry for came too late, but i had this problem and i wanted to show how i fixed for the next devs who need a solution:
It's quite simple, just change your proyect assembly name:1) On your solution explorer: Right click on your proyect.
2) Properties>> aplication>> assembly name>> change it.
3) Compile, run to test it.
4) Change the name again if u wanted the original name.
Adding a description:
Changin the assembly name
New 2 programing in VS but i had same problem of Access or Write exe file ON BUILD.
Problem came out of nowhere. I didn't use or make changes 2 exe file in months,
made exe file, used it now and then and forgot about it....
Then after few months i wanted 2 start exe but no icon on desktop ??? ....tried everything, lost 3 days of searching inside code for error in VS and then called Google....
I read last comment ABOVE which mentioned Bitdefender, opened it and found BitD did block and isolate exe files ..... so i tried exluding files and folders which made problems inside BitD but no help....
So i went back 2 VS.
Within debug i got some X86 processor error which didnt make problem to build but it was warning (free component name in error description helped me ), - errors you can ignore but they are here on build ....
So i made last move before starting it all over again. Removed COMPONENT from application, deleted it on PC ...started VS from start .. and ALL was OK !!!
So in my case it was all about FREE component i used in app inside VS .... Bitdefender found some add / virus in it and blocked build progress.
BitD deleted or blocked exe file in start....
Hope this help anyone with similar problem !
The cause of this error for me was that Team Foundation Server had pulled in a bunch of files to my work space as Read-only. Not sure why it pulled them down from the server with read-only checked, but all I had to do was uncheck it.
Ok. Create a new solution and add its directories to the exception list and copy all your work, except for the '.vbproj' and except for the '.csproj' and the directory files to the directory of the directory of the new solution. I have tried that and it works, due that I have Bitdefender, it will be the only way to sort that issue. After doing so, try to build the app again. If it does not work, then I am definitely out of ideas.
I've installed the Visual Studio 2013 Preview to try out and I'm having some very bad performance issues. Every time I open a file and immediately try to close it, edit a file, save a file, etc. the IDE will stop responding for about 15 seconds.
I've gone through every performance tweak I could find through stackoverflow, blogs, web search, etc but none have worked (for example, clean up temp folders, disable add-ins and extensions, delete .suo file, etc.).
Using /safemode, the performance problems go away but I can't find what could be different since I have no add-ins, nuget packages, or extensions installed.
Using SysInternals Process Explorer, I can only see the process for devenv.exe peg the core it's using at 100% when it stops responding. I am not seeing any network or hard drive activity during this time and no other processes become active.
I've reinstalled with no luck, and I've installed it on another development machine where it seems to work just fine.
Anyone have any ideas?
Thanks!
UPDATE: In Process Explorer 'Other I/O Delta' shows ~200,000/sec when it locks up on the devenv.exe process. Still looking...
UPDATE 2: I guess I should add that this PC is a Dell Vostro 460, i7-2600 # 3.4Ghz, 8GB RAM, Windows 7, 1TB HDD with 550GB free, plenty of power for what I'm doing. Closed all other apps while debugging, including VIPRE A/V and Malwarebytes.
UPDATE 3: Maybe getting closer... using Process Monitor (love SysInternals stuff!) for some reason my entire C:\Projects\ folder is being parsed/searched by devenv.exe. I keep all my project folders under C:\Projects\ where there are about 20 projects each with their own sub-folder. Here's where it gets weird. In /safemode, devenv only parses the current project's folder, not the entire parent folder. Projects has 6,271 folders with 29,914 files. I tried creating a new c:\Projects2013\ folder, created a new test project, and devenv is trying to parse the full parent Projects2013 folder, yet in /safemode only parses Projects2013\Sample.
Obviously though the new project in Projects2013 runs full speed because it's parsing far fewer files. The other computer runs fine because I left the default Projects path and there were no other projects in that folder. Now what in the world could be doing this and why the different folder path between regular and safe mode? Time to dig through Tools, Options... ugh!
Here's a screen grab from ProcMon:
Final Update - Resolved! It was git causing the problem. I had a local repository set at c:\Projects\ which contained all my various project sub-folders. The dump file I created for them allowed them to narrow it down to git. Removing the local repository fixed my performance issue where VS 2013 is at least usable now. The programming team still needs to resolve the continuous re-parse of the folder though. Anyone with a very large repository will end up with this issue.
RESOLVED! It was git causing the problem. I had a local repository set at c:\Projects\ which contained all my various project sub-folders. The debug dump file I created for the VS programmers allowed them to narrow it down to git. Removing the local repository fixed my performance issue where VS 2013 is at least usable now. The VS programming team still needs to resolve the continuous re-parse of the folder though. Anyone with a very large repository will end up with this issue.
Using Visual Studio 2010, when I build + run my application in short intervals I often get the following error. If I just wait a minute or two and try again it works fine. Unlocker claims no handle is locking the executable file. How can I discover what's locking it? If it's Visual Studio itself, what should I do to make it stop? or alternatively to release the file?
1>------ Build started: Project: MyProj, Configuration: Release Win32 ------
...
1>InitializeBuildStatus:
1> Creating "Release\MyProj.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1> All outputs are up-to-date.
1> SomeFile1.cpp
1>ResourceCompile:
1> All outputs are up-to-date.
1>LINK : fatal error LNK1104: cannot open file 'D:\...\MyProj.exe'
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:00.94
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Had this issue after a reinstall today. Make sure the Application Experience service is started and not set to disabled. If its set to manual, I believe VS will start it.
I'm aware this is quite old but I just had the same problem with Visual Studio 2010 all patched up so others may still run into this.
Adding my project path to "Exluded Items" in my AVG anti-virus settings appears to have fixed the problem for me.
Try disabling any anti-virus/resident shield and see if it fixes the problem. If so, add your project path to excluded directories in your AV config.
You probably had a stray build process that was locking the executable, and it (the stray process) didn't get cleaned up. In that case, shut down visual studio, open up process explorer, and nuke every process you can find that is related to visual studio.
Then open up visual studio again and try rebuilding your project.
the file can be locked because it is being run now. Try killing the process with a task manager.
Like Jonathan said, yes, renaming can help to work around this problem. But ,e.g. I was forced to rename target executable many times, it's some tedious and not good.
The problem lies there that when you run your project and later get an error that you can't build your project - it's so because this executable (your project) is still runnning (you can check it via task manager.)
If you just rename target build, some time later you will get the same error with new name too and if you open a task manager, you will see that you rubbish system with your not finished projects.
Visual studio for making a new build need to remove previous executable and create new instead of old, it can't do it while executable is still runinng. So, if you want to make a new build, process of old executable has to be closed! (it's strange that visual studio doesn't close it by itself and yes, it looks like some buggy behaviour).
It's some tedious to do it manually, so you may just a bat file and just click it when you have such problem:
taskkill /f /im name_of_target_executable.exe
it works for me at least.
Like a guess - I don't close my program properly in C++, so may be it's normal for visual studio to hold it running.
ADDITION:
There is a great chance to be so , because of not finished application. Check whether you called PostQuitMessage in the end, in order to give know Windows that you are done.
You might have not closed the the output. Close the output, clean and rebuild the file. You might be able to run the file now.
I've concluded this is some kind of Visual Studio bug. Perhaps C Johnson is right - perhaps the build process keeps the file locked.
I do have a workaround which works - each time this happens - I change the Target Name of the executable under the Project's properties (right click the project, then Properties\Configuration Properties\General\Target Name).
In this fashion VS creates a new executable and the problem is worked around. Every few times I do this I return to the original name, thus cycling through ~3 names.
If someone will find the reason for this and a solution, please do answer and I may move the answer to yours, as mine is a workaround.
I had the same problem, however using Codeblocks. Because of this problem i quited programming because everytime i just wanted to throw my computer out of the window.
I want to thank user963228 whos answer is really a solution to that. You have to put Application Experience on Manual startup(you can do it by searching services in windows 7 start menu, and then find Application Experience and click properties).
This problem happens when people want to tweak theyr windows 7 machine, and they decide to disable some pointless services, so they google some tweaking guide and most of those guides say that Application Experience is safe to disable.
I think this problem should be linked to windows 7 problem not VS problem and it should be more visible - it took me long time to find this solution.
Thanks again!
Just to add another solution to the list, what I've found is that Visual Studio (2012 in my case) occasionally locks files under different processes.
So, on a crash, devenv.exe might still be running and holding onto the file(s). Alternatively (as I just discovered), vstestrunner or vstestdiscovery might be holding onto the file as well.
Kill all those processes and it might fix up the issue.
I have just run into the same issue with VS2013, creating device drivers in C++ , and none of the above seemed to fix the issue. However, I have just discovered that in my case the issue appears to have been VMWare-related.
I was running a VMWare workstation client with a shared folder defined on the VM on my entire C: drive. When I disabled the shared folders on the VM Settings, VS2013 was able to happily build my .exe files.
My new process is:
1) Disable the shared folder on the vm (VM Settings | Options | Shared Folders - and uncheck the checkbox)
2) Run the build on the host PC
3) RE-enable the shared folder (and proceed from there)
Hopefully this might help someone else.
(BTW, the errors you receive are that the .exe (or other files) are locked or require Administrator permission, but that is a red herring - It seems to me that the VMWare share is causing those files to appear as locked.)
Usually, this means that your program is locked and might not be killed through task manager or process explorer. I met a similar case that my program had an exception during running and triggered the windows error reporting which locked the program. For the case that windows error reporting locks the program, you can go to control panel->System and Security->Action Center->Problem Reporting Settings to set "Never check for solutions". Hope it helps.
For me it was happening, when I was trying to build in debug mode, but it was working fine in release mode. I changed the build configuration in the visual studio from x86 to x64 and it worked fine for me, as I was running on 64 bit system.
I just had this issue in VS22 - I think I closed the debugger right when it was compiling. All I had to do was restart my computer.
The error comes (at least sometimes) from paths that are too long. In my project simply reducing the output file path does the job:
"Properties/Configuration Properties/General/Intermediate Directory"
Seems that I have hit the 250 character path limitation.
Working with Bjarne Stroustrup Programming Principles and Practice Using C++ "FLTK" example i got the same error but after like 1 hour i got an idea, i tracked one of the libs already seen in Project Properties -> Linker -> Input -> Additional Dependencies, in my case i tracked the kernel32.lib to see where was located and saw there were many kernel32.lib's in different folders. So i started copy the FLTK libs in those folders and the last one i tried worked. Visual Studio 2013 Express found the fltkd.lib and the code worked.
In my case the correct route was C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86
I don't know how to set that route inside Visual Studio.
Not sure if that Windows kits folder was created when i installed Microsoft Windows SDK for Windows 7 and .NET Framework 4 (ISO) http://www.microsoft.com/en-us/download/details.aspx?id=8442
Hope that helps you people.
I just had thesame problem. With me the exe was still running but I could not end it with the Task Manager. Just by restarting VS, it worked for me.
Mine is that if you set MASM listing file option some extra selection, it will give you this error.
Just use
Enable Assembler Generated Code Listing Yes/Sg
Assembled Code Listing $(ProjectName).lst
it is fine.
But any extra you have issue.