Related
I have an issue while I try to build project in VS2012.
It cannot build due to the error:
Couldn't process file xxx.resx due to its being in the Internet or Restricted
zone or having the mark of the web on the file. Remove the mark of the web if
you want to process these files.
Here is a similar question.
but I tried that option and had no luck, because I did not download the file from the internet. That project was built from scratch. In project after selecting Properties, in Windows Explorer nothing happened. I do not have the "unblock" option, only the default three options (read only, hidden, and archived).
I have the same error and cannot build or rebuild the project. I have a theory that it is a recent error after updating Windows. Before the update, everything worked fine. Any ideas?
Go to xxx.resx file in Windows File Explorer. Right-click and select properties. At the bottom of the the dialog is an "unblock" option:
Check this and click Apply. Clean your solution and it will build.
In my case I had the same problem with many files.
My solution with VS Prof. 2017 V15.95 was:
Open powershell and execute dir -Path [directory path] -Recurse | Unblock-File
Rebuild all
On the solution folders locate abc.resx.
Open the file using any text editor, preferably Notepad++.
Locate and delete any node starting with <data
Example. This is what you should delete.
<data name="$this.Icon" type="System.Drawing.Icon, System.Drawing" mimetype="application/x-microsoft.net.object.bytearray.base64">
<value>
AAABAAMAICAAAAEAIACoEAAANgAAAGBgAAABACAAqJQAAN4QAACAgAAAAQAgACgIAQCGpQAAKAAAACAA
AABAAAAAAQAgAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
///////////8AAB/////////
</value>
</data>
Reload or reopen your solution and build. You are ready to go.
Had the same problem after updating to VS 2017 v15.8.5, and none of the solutions above or on other forums worked for me.
So, since a .resx file is just XML, I just copied the content, deleted the original file and recreated it with the copied content.
That was the only thing that worked, and it worked first time.
A quick way to remove this mark of the web for multiple files and folders recursively for me was to
Zip them up.
Delete originals.
Unzip.
I'm not really sure either, I have the exact same issue.
But, what i did, was hit view in file explorer.
Then, i clicked show hidden items.
Finally, i went back to my folder and clicked on the .vs folder, my project/file name, v15, Server, sqlite3, and deleted DB.Lock.
I reopened the project, clicked build, and it worked perfectly.
This worked for me, it might/might not for you.
I also encountered this issue recently. The error began occurring after I set the icon of a Windows Form.
Researching for the cause and solution almost led me nowhere, because I did not download the icon from the internet, nor was I referencing a web-based icon file. It was stored entirely on my local machine.
After some more researching and digging around, I was able to figure out exactly what was causing the problem. I have Microsoft One-Drive installed on my machine. The directory in which the icon file was located is managed/synced by One-Drive. That fact was somehow tricking Visual Studio into believing the file was located or downloaded from the internet.
The solution proved to be very simple. I removed the icon from the form, as well as from the corresponding .resx file. Then I moved the icon file to another directory not associated with One-Drive. Finally, I was able to use that icon in my Windows Forms application without getting this error.
I understand there are other possible causes for this error. But if in your case, the issue happened after setting a form's icon--and if you have One-Drive (or perhaps another cloud-based storage solution) installed--then check to be sure that icon file is not in a directory managed by that service. If so, relocate it and change the form's icon property to point to the new location.
To fix this for multiple files within a project, Visual Studio -> Tools -> Options -> Trust Settings and add the project path as a trusted path.
Using VS 2019, and building against source stored on an Azure shared file system. I think I may have just tracked down a work-around, and it has to do with the Icon as referenced above by Jake above. If I add the icon to the form's resource file (that really long string), The error occurs.
However, if I add the Icon to the Project's resources, delete the Icon from the form's resource file, and change form to set the Icon manually...
this.Icon = MyProjectName.Properties.Resources.MyIcon;
The error goes away.
I found this solution on another forum. My project resided on a file share, so I had to enter file://[file share] for Step 4 below. I am running VS2019 on Windows 10.
Start Menu > type 'Internet Options'.
Select Local intranet zone on the Security tab then click the Sites button
Click Advanced button
Enter file://[computer name] or file://[file share]
Make sure 'Require server verification...' is unticked
I had the same issue in Windows 10 VS 2019 16.4.457 (previous version of VS 2019 had no problems).
The "marked for web" error shows only after I moved the project under One-Drive.
If I move the project back to a local drive the error doesn't show.
As Anthony Gingrich suggested, I tried to move the project images to a local directory without success.
The solution that works for me was, for each image, in the "Select Resource dialog" use "Project resource file" instead "Local resouce".
Please guys, I already fixed the issue, this is cause by OneDrive, please close your OneDrive with the use of task manager or close the icon OneDrive's Hidden Icons on the taskbar
I just ran into the same issue and also tried the Unblock option from explorer with no luck. I even restarted VS with no luck.
However, I'm not sure which combination did the trick but I opened the form as well as the resx file from within VS, just to see if I can open it, which opened fine. I then did a clean and rebuild and that appeared to do the trick. If it doesn't try restarting VS after the clean then rebuild.
I had a similar issue and the problem was an image that I had downloaded and added to my Resources. Not completely sure why that was the only image that gave me problems, however, I opened my abc.resx file giving me issues an a text editor, removed the node starting with " (it was the last and only node) just like Albert Alberto mentioned. Saved the changed, cleaned and rebuilt my solution and it all works! The image didn't render but it only took a second to go back and add the image. It wasn't removing the entire file, just the node that was causing the issue.
I had the same problem on Windows 10, VS 2017 (15.9.13). I sent myself a project from work through Dropbox so I could try a couple of things from home. But when I tried to build it VS gave me the 'marked for web' error.
After trying the solutions above without success I began experimenting. I was able to solve this by using the method listed above (right click -> properties -> unblock), but I had to do it for each of the images in the Resource folder--and I had to do EACH FILE individually since the 'unblock' option was not available on group-selects. I actually unblocked each source file in the project as well before trying to rebuild so I am not sure if both are required.
Its a bit of a pain--probably a huge pain for larger projects--but it absolutely got the project building again.
EDIT: I did find this article afterwards about unblocking entire folders--even recursively but have not tried it: https://www.winhelponline.com/blog/bulk-unblock-files-downloaded-internet/
None of these worked for me. I fixed it by converting the embedded base64 into a linked resource:
I found out the issue was with the embedded base64 image I had in the .resx (as the issue went away removing the data tag as explained in this question but that meant I removed the image) so I converted the embedded image into a .png file and made a link to that in the .resx.
To do that: open the .resx file in Visual Studio 2019 and double-click the image, and then click Ok and Yes in the following prompts that will appear so VS will convert the embedded image into a linked resource (sorry I can't upload pictures yet):
Hope it helps!
From my original comment.
I'm running my .NET 4.0 (C#) project in debug mode after I start VS2013. It runs just fine.
The second time I start it from VS, I get the Dialog box that says "Error while trying to run project: Unable to start program C:\path\to\file.exe"
The process is still alive in the Taskmanager when I dismiss the dialog box.
From Windows Explorer, I can run the program just fine. And after closing it, the process is gone too from the Task Manager.
A rebuild doesn't help.
Is this a common problem with a known solution?
I had an issue similar to this and I had to clear the component cache instruction can be found Here.
Hope this helps.
For my case, it cause by Platform target, you could force choose it to x86 or x64 which your project is:
Each Project's Properties > Build > Platform target
As I pointed out also here, the only solution that worked for me was to disable the ConEmu integration:
ConEmu → Settings → Integration → Default term → disable Force ConEmu as default terminal for console applications
Some users reported that it was enough for them to disable the Aggressive mode in that same settings tab; that wasn't the case for me though.
The topic is old, but this might help someone else.
So in my case I made a file in Visual Studio with .cp extension (accidentally deleted the last 'p') this made visual studio just "include" the the file and not mark it as a compilation unit, thus not compiling it, I looked the *.vcxproj file in a text editor and found out about this, so if you open the project file in a notepad or something just find your file at the bottom usually and change from <Item .../> to <ClCompile .../>
I was getting similar errors. I just had to restart visual studio. Sometime couple times a day.
I had a similar error and resolved it by cleaning the solution. Right-click the solution name in Solution Explorer and choose Clean Solution.
I found a solution here:
Please check "Use Managed Compatibility Mode" under Tools|->Options->Debugging->General.
I'm Brazilian, I don't speak English very well. I did this translation on google translator.
I know the topic is old, but it can still help someone.
I had this same problem in the following situation, I have a dual boot computer (linux debian 11 and windows 10). Inside debian, on my NTFS D disk, I created a folder to perform programming tests. After accessing that same folder with windows, I created a new project in visual studio inside that same folder that I had created in linux. The creation of the project went without problems, however when I tried to run the project (F5), I received the same error from this topic. I tried all the solutions I found on the internet, and nothing worked. I gave all permissions to my admin user and it still didn't work. Then I realized that even going straight to the folder where the application's executable was and clicking directly on it, I still received the access denied error message. So, I took the project out of the folder I had created in linux, and it worked. So, what I could conclude, is that because the folder where my project was was created in linux, for some reason, my windows didn't trust this folder, so it didn't allow running executables from inside that folder, even this one executable having been created by visual studio from within windows.
Just simply create a folder name as "projects" in c drive and copy paste the newly created project in it. Run the project by doing clean & Build or Rebuild method . It will work
open the folder which contains the solution in visual studio.
again, open your *.sln file by double clicking it inside the solution explore once opened try running the solution or rebuild the solution. once rebuild gets completed, it will open without error from next time.
My way of solving the error : error while trying to load project : Unable to start program and c:\Path\to\file.exe was simply by
First restart Visual Studio
Click the build icon
Select the rebuild option
Run the Program or Debug the Program
This was a weird one. Going to put what happened to me here because it might happen to someone else. Everything was fine with the app until suddenly after some fairly insignificant code changes I suddenly started getting this error. Visual Studio was compiling the executable just fine. But, the moment I tried to run it (either from Visual Studio or directly) the executable file would be automatically deleted right out of the Debug folder. Super odd--never seen anything like it. I began to get suspicious that perhaps an anti-virus or the OS was somehow identifying a checksum or some signature in the executable as "dangerous". Or perhaps some obscure compilation bug was corrupting the executable. So on a hunch I made another innocuous change (added a couple of lines of code to color code some text in a rich text box) and the problem went away.
I have created a vsix plugin for VS 2015 that receives some data of a REST-Service, writes it into a file and then it adds the file to my C# Project.
Well the problem is that after the files were written on the file system and integrated to the project my user input in visual studio is blocked:
e.g. I can write for example "asdf" in a code file, but when I try to delete the text with the backspace button it is not working. Other buttons like CTRL are also not working.
The interesting part is when I close VS2015 the following error appears:
The problem is definitly caused by this line:
project.ProjectItems.AddFromFile(filePath);
project is an EnvDTE.Project object! The thing is the files were added to my project but I have to kill and restart VS to continue with my work.
I have also found a little workaround: When I disable TFS in my project all is working fine!
So my conclusion is that the problem is caused by TFS!
Can anybody tell me what I can do, to solve this problem! It costs me a ton of time to restart VS every time!
When using TFS, you need to checkout the project for modification first, use SourceControl.CheckoutItem: https://msdn.microsoft.com/en-us/library/envdte.sourcecontrol.checkoutitem.aspx
The problem here is not what you are doing, but how. Some modal window you are opening it's been locked to the screen. Make sure you closed it correctly.
This behavior it's common when using modal. Try to figure it out what window you are opening and try change it from modal to not-modal.
It will stop this problem.
While trying to debug an asp.net website in visual studio 2013 professional I am having a weird issue. The website is simple but uses flat files and folder structure and files in it for performing some operations. There are two important folder in this website that contains 100 thousands of files and images. When I try to start debugging and do not remove files from these two folder then VS crashes and restart, but if I remove files then VS proceeds normally. The files in these folders are csv, txt and image files. What I can understand is that VS goes through all these folders and files before starting the debugger, hence somehow I need to tell VS to not to consider these folders. I am not able to find anything related to it. Please help. Thanks in advance.
Perhaps take a look at your Event Viewer first and see if you can find anything regarding VS crash.
Also you can try running Visual Studio from the command line devenv.exe /log and then load your solution. If crash still happens, then go take a look at following file %APPDATA%\Microsoft\VisualStudio\<version>\ActivityLog.xml. Perhaps you would find some more details about the crash.
If you happen to be using ReSharper, you might want to disable it and see if that would make any difference. ReSharper likes to index source files in the background which could lead to some usability issue in VS.
Answering for anybody who faces similar problem.
For some reason I dont know why, when starting degugging visual studio was scanning each and every folder, even the folders which doesnt contained any code file, this was making VS very slow due to very high number of files and out of memory exception was being thrown. Since in my case these folders doesnt contained any code file, but still were needed to run the application, I made them hidden from window explorer. This solved the problem as now vs ignores them, while still the program can output report and read reports from these hidden folders.
I've got a C# webforms app, that until today had been working just swimmingly.
Now today, all of a sudden, every time I try run the app, I get a file locking error:
Unable to copy file "obj\Debug\MyProject.exe" to "bin\Debug\MyProject.exe". The process cannot access the file "bin\Debug\MyProject.exe" because it is being used by another process.
Googling the error doesn't come up with anything beyond the obvious, i.e. VS thinks the file is locked. And it is definitely Visual Studio itself that locks the file, because when I close VS and reopen it, the project executes fine - the first time. When I try to run it a second time, I get the file locking error.
Closing VS and reopening every time I want to run the app is not a viable workaround! How do I find out what's locking the file, and stop it from getting locked?
EDIT: Another interesting discovery: I don't even have to run the app. Just compiling it once causes the file locking; I cannot compile twice in a row!
This problem is specific to one project in my solution. All other projects work fine and can be executed as many times as I like. It's only this one project that gets itself locked up.
I have found a simple solution which works for me. It goes like this:
When the problem occurs, just change the building configuration at the top (if in “Release” to “Debug” and vice versa), build and then change back to previous configuration and build again.
I suppose that changing the configuration releases the vcshost and devenv.
Well, I solved the problem myself - though I still have no clue why. I decided to isolate the problem by removing all files from the project, then re-adding them and determining that way which file was the source of my trouble. So, one by one I reintroduced files to the project, compiled & cleaned each step of the way... until... I added the last one...
... and everything still worked fine.
I did a compare to the source control of my original .csproj; no real differences. And even when I tried reverting to the previous version of the .csproj, it still worked.
Black magic. If it works, sometimes it's better not to ask why - just accept it and move on...
EDIT: The problem is a recurring one, and I believe I've isolated it to when I have the form designer open of an abstract/generic form at compile time.
Lesson learned: Make sure the Form Designer of any abstract or generic forms or controls is closed before you compile! If not, you have to close VS and reopen!
What we have discovered here, is the following:
In the project properties page, Debug tab, uncheck the "Enable visual studio hosting process".
I am unsure what this property is for, but it does the work once unchecked.
Solved by closing all instances of MSBuild.exe in the windows task manager
Actually you should want "Enable the Visual Studio hosting process" checked. At least for VS2010 anyway. And I also have:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
in the pre-build options. This problem has dogged me for a very long time and it wasn't until John W. mentioned this check box that I even took notice that it existed and low and behold it was already unchecked.
Also notice that -app-vshost.exe runs in the background even when not debugging. Which is what makes it successfully build and run every time I guess. It wasn't running before. And I also tried cleaning out the debug and release folders and changing the target type constantly and nothing worked except as described above. My solution before was to just wait 5 minutes between builds, which got super annoying and time-consuming to get anything done. I haven't seen any change in behavior where it mattered what tabs where open or XNA vs windows form or designers being opened. This issue occurred in 32-bit or 64-bit builds and didn't matter if I killed an app with ALT-F4 or killing it with task manager, which would, in theory, not allow the app to close or release resources. At first I thought it was a garbage collection issue.
I have overcome this problem by renaming the locked file (using Windows Explorer). I was not allowed to delete the file, but renaming the locked file works!
Little late to answer, but I solved this by going to the properties of the project > tab "Debug" > unchecked "Enable the Visual Studio hosting process" option.
I solved this by deleting the folder bin\Debug and, possibly, restarting VS
Run this command from the Run box:
net stop iisadmin /y
and then
iisreset
worked for me.
vs 2003
For me, it was a Windows Service that was installed and running. Once I stopped it, the build was successful.
I had a similar error but during the deployment of the UWP application. Finally, I found out the process that used a file that caused this error and stopped it. Credits to this link. Copy-pasted version is below.
How to Solve the Issue?
One of the easiest ways to handle locked files or folders is to use Microsoft Sysinternals Process Explorer.
Identify what program is using a file
Using Process Explorer there is a simple way to find the program:
Open Process Explorer (running as administrator).
On the toolbar, find the gunsight icon on the right.
Drag the icon and drop it on the open file or folder that is locked.
The executable that is using the file will be highlighted in the Process Explorer main display list.
Identify which handle or DLL is using a file
Open Process Explorer (running as administrator).
Enter the keyboard shortcut Ctrl+F.
Alternatively, click the “Find” menu and select “Find a Handle or DLL”.
A search dialog box will open.
Type in the name of the locked file or other file of interest.
Partial names are usually sufficient.
Click the button “Search”.
A list will be generated.
There may be a number of entries.
And then kill this process.
Unfortunately none of the answers worked for me. This is what solved it:
Win Key + R and run resmon.exe. There you'll find the EXE process that VS claims to be using the file. Right click and end the process. Although you might get an Access Denied error message, it will be suspended and you'll be able to build again.
Recently ran into this problem when attempting to build a solution I am working on (not just a winforms proj).
In addition to build failure, I noticed that cleaning projects would quietly fail (checking the bin folder showed that the files had not actually been erased) and closing the Visual Studio did not end the devenv process - rather, it caused it to crash. Windows recovery process would then restart the Visual Studio.
After some trial and error, I found the problems only happened to me when I opened the solution from the "Recent" menu on starting up VS.
Opening the solution from File >> Open >> Project/Solution found it working as per usually.
Currently no idea why - will keep looking into this but for now, at least I can work!
Just check the references and remove the self-reference to the project.
Explanation: My problem started after creating a custom control and drag and drop it to the toolbox palette for use it in design forms. First appeared a warning saying that there was a redundance between the custom control source file (.cs) and the projects executable (.exe). On executing/debugging appeared the error: unable to access the (.exe) because it's being used (and it was true).
I literally removed the whole source code regarding the custom control and the problem still remained, until I checked out the references and it was referencing itself in order to be "able to" get the former custom control. I removed the reference and done!!
I had the same issue on my Xamarin application in visual studio and it was resolved by unplugging my test mobile device. The application was closed and the debugger was stopped but the error was still happening when trying to build or rebuild the solution. It only stopped after i unplugged the device because i had to receive a call.
Just to throw in my 2 cents. My issue was solved by opening Task Manager and killing the application. It was running in the background without any indication that it was running at all (no item in the task bar, no ui, nothing), but I am not sure why this happened. Obviously the debugger was not running and I only had a single instance of VS opened at the time. It amazes me that this is still happening in this VS 2017.
Perhaps I can add a build step that looks for the application running the background and kills it before starting the new one.
I had the same issue and could not rectify by using any of the methods mentioned in previous answers. I resolved the issue by killing all instances of "SSIS Debug Hist (32 bit)" in task manager and now working as normal.
I had this issue (and its an issue I have seen in other places not just VS).
It's caused by Dropbox (in my case). After editing some code and hitting run, sometimes dropbox immediately locks the file (so it can process it).
Solution 1.
Just hit run again
Solution 2.
Pause dropbox. (not good if your using dropbox as your cloud backup)
Solution 3.
Remove the build folder from dropboxes sync list.
Deleting Obj, retail and debug folder of the .NET project and re-building again worked for me.
This got me stuck for over two days, had to reclone the project and save the project folder in a different name, but today I found the solution from a microsoft dev forum.
solution:
Create a pre-build action in your project by going to project properties (right-click on the project in the solution explorer, and select the Properties option), select the Build Events tab. Add this code:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
This code will copy the file to a different name, and allows the build to continue successfully.
How is your web app configured? Does it run under Cassini (the tray web server) or IIS?
This shouldn't happen normally though. I think ProcessExplorer can tell you what files a process has locked. If not process explorer one of the other sysinternals tools.
One thing to try before even downloading one of the SI tools is to stop the Cassini web server, and seeing if that frees up the file.
What worked for me was restarting IIS
i had this same problem as well. changing the debug/release config didn't do the trick. at least not without building in between.
in my solution (winform) it was solved by opening the mainform of the winform in the designer. switching to code (F7). Then closing the code, closing the designer of the winform and rebuild all (ctrl-shift-B). This worked for me.
seems like some kind of handle from within the winform app (which runs a backgroundworker) still had a file handle on some of the other libraries used.
I had two instances of Visual Studio opened the same solution.
In my case there were some vstest processes running (with various names but all containing the string vstest). I had to terminate them in taskmgr.
Same error, solved by updating Google Nuget support packages
When I ended the process .Net Core Host, everything built fine. I didn't have to close Visual Studio or do change anything else.
For those who are developing in VS with Docker, restart the docker for windows service and the problem will be solved immediately.
Before restarting docker I tried all the mentioned answers, didn't find a msbuild.exe process running, also tried restarting VS without avail, only restarting docker worked.
One more solution: when the files get locked, blocking process is reported (something like "ServiceHub.Host.CLR.x64 (7764)") with it's id in parentheses.
To get rid of the process, open PowerShell (x + Win + I) and type: "Stop-Process -Id idNumber".
I recently ran into the issue when deploying to Service Fabric. The error is implying a 'file' is in use, however, I found that the port was being used by another IDE. By stopping a running service which was already hosting on the port, I was able to stop this exception from occurring.