I am trying to build a project on visual studio 2019, which has a <filename>.resx file.
I get the following error when I build it:
error MSB3821: Couldn't process file <filename>.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.
I researched and found that I can unblock the file by right clicking on the file from file explorer and going to properties. But I don't have an unblock option.
Related
When I update a cshtml file in my MVC project in Visual Studio 2015, the html changes are not getting updated when I refresh the browser. I am using chrome and have dev tools open. Dev tools is set to disable cache when open. If I clean the solution and rebuild then the my change makes it successfully. But If I just refresh the browser the update does not happen. If I delete all my temporary internet files and start debugging again, I can sometimes make a few changes to the cshtml files and they will work when I refresh but after a little while it stops working.
I have noticed that when it works correctly visual studio is creating 2 files named app_web_(some junk letters).dll.delete and another other titled the same called .pdb.delete. When I refresh the browser it creates a bunch of new files and my html change makes it to the browser.
When it stops working visual studio no longer creates the delete files in the temporary internet files folder.
For the record they are in the root directory of temporary internet files.
Also, this solution was originally created in VS 2013 but I am now using 2015. It always worked when i used 2013
The problem is most probably caused from caching problems on the related Windows directories that Visual Studio or web browser use. For fixing the problem you might try to clean the contents in the following cache folders (do not delete these folders, instead delete their contents only) and restart Visual Studio:
Clean the content in WebSiteCache folder (can be found in C:\Users%USERNAME%\AppData\Local\Microsoft\WebSiteCache)
Clean the content in Temporary ASP.NET Files folder (can be found in C:\Users%USERNAME%\AppData\Local\Temp\Temporary ASP.NET Files)
Clean Asp.NET Cache in root folders (can be found in
C:\Windows\Microsoft.NET\ Framework\ ... \Temporary ASP.NET Files\root or
C:\Windows\Microsoft.NET\Framework64\ ... \Temporary ASP.NET Files\root)
Delete the browser history by selecting the period from the beginning.
And then restart Visual Studio. If the problem continues you might try to rename the project folder and reopen it again.
Try with hard reload:
Push F12 on Windows (On Mac: Cmd+Opt+I) then you can right click on refresh and select 'Empty Cache and Hard Reload'
from https://superuser.com/a/512833
I am getting the following error when running my build on Visual Studio Online (using the built-in Build Controller):
C:\Program Files
(x86)\MSBuild\14.0\bin\amd64\Microsoft.Common.CurrentVersion.targets
(3962): Could not copy
"d:\a\src\MySolution\MyProject\Trunk\packages\Microsoft.Data.Edm.5.6.4\lib\net40\Microsoft.Data.Edm.xml"
to "..\Build\bin\Release\Microsoft.Data.Edm.xml". Beginning retry 1 in
1000ms. The process cannot access the file
'..\Build\bin\Release\Microsoft.Data.Edm.xml' because it is being used
by another process.
It is never the same file either but it seems to always be either an xml or dll from the packages folder.
EDIT: I'm not sure if it is worth mentioning, but I do have multiple workspaces and multiple build definitions using this repository.
I found the problem. Completely unrelated to the error above.
I went into the msbuild log files and found this:
Failed to produce diagnostics extension's config for
MyRole\diagnostics.wadcfgx. Error : Could not find a part of the path
'd:\a\src...\MyRole\diagnostics.wadcfgx'. Done Building Project
"d:\a\src...\MyCloudProject.Cloud.ccproj" (Publish target(s)) --
FAILED.
I was missing a file in source control.
I do wonder why this error did not bubble up into my build summary. And where did that initial error come from?
I am using TFS with Using Visual Studio 2013 and have been able to work around this issue by closing all open documents that I want to check-in (seems VS locked itself out) and/or resolving conflicts. The error message is sufficiently vague so as to be useless as to the actual cause of the check-in failure.
Update 02 November 2016:
I'm not sure why VS 2013 and TFS don't play nice together via the Team Explorer Check-in Pending Changes button, but it consistently fails to launch the conflict resolver, a key piece of the check-in process.
The following works for me on VS 2013 and TFS hosted on a SQLServer Express 2014 database:
1. Launch the Source Explorer: Team Explorer tab -> Source Explorer
2. Navigate to your solution repository
3. Then proceed to do the following for each project that you want to check in:
a. Right click project
b. Check in pending changes
c. Resolve conflicts and repeat steps 3a and 3b until no pending changes remain for the project
I am using Visual Studio 2013 and Team Foundation Server 2013. I have these, as well as the Build Controller/Agent, running on my personal computer, called "FUSROHDAH".
My goal is to take a build generated by the TFS Build Agent and open it for debugging in Visual Studio, and have it leverage the source indexed PDB to access the source code from the TFS source control system so that I can step through the code. I have studied several informative articles about PDB's and source indexing, including:
Ed Squared's article on Source Server and Symbol Server Support in TFS 2010
John Robbins' article about PDB files
I also watched John Robbins' very excellent video on WintellectNOW which discussed a lot of the nuances of setting up the symbol server, source indexing.
However, despite several days of hair pulling, I haven't been able to get this working yet.
I've set up TFS for continuous integration. Here are my settings:
In Build Definition->Build Defaults, I have set Staging Location to "Copy build output to the following drop folder (UNC path, such as \server\share)":
\\fusrohdah\builds (this equates to c:\builds on my machine)
Build Definition->Process Template Settings:
Path to Publish Symbols: \\fusrohdah\symbols\ (this equates to c:\symbols on my machine)
I notice that the Default Process Template in TFS 2013 looks different from the articles discussing TFS 2010. In Ed Squared's article, there is an option for "Index Sources". In TFS 2013, this setting is gone, and in the instruction text, it says "Specify the path to the symbol store share. When this value is set, source indexing is a part of the build." So I assume that I have source indexing running on my builds, by simply specifying this location.
So I take a simple console application HelloWorld and I perform a series of changes and check-ins. I observe the builds are published to the builds folder as I would expect, with an EXE and PDB file side by side.
So I want to take an older build and debug it in Visual Studio, and step through source code obtained from the TFS source indexing. I open the EXE in Visual Studio and hit F11 to launch the console application and begin stepping into the code in the Main() procedure. But, when this happens, I get this message:
--------------------------- Microsoft Visual Studio
--------------------------- Source file: C:\builds\2\LocalTestProject\HelloWorld\src\HelloWorld\HelloWorld\Program.cs
Module: C:\builds\HelloWorld\HelloWorld_20140722.6\HelloWorld.exe
Process: [6016] HelloWorld.exe
The source file is different from when the module was built. Would you
like the debugger to use it anyway?
This seems to be the crux of my problem. My understanding is that when Visual Studio reads my PDB file, it should execute TF.exe to obtain the correct version of the source code from TFS, and it seems to be failing to do this. I used PDBStr.exe to look at the PDB file published by the build, and nothing seems amiss:
c:\builds\HelloWorld\HelloWorld_20140722.6>pdbstr -r -p:helloworld.pdb -s:srcsrv
SRCSRV: ini ------------------------------------------------
VERSION=3
INDEXVERSION=2
VERCTRL=Team Foundation Server
DATETIME=Tue Jul 22 23:04:51 2014
INDEXER=TFSTB
SRCSRV: variables ------------------------------------------
TFS_EXTRACT_CMD=tf.exe view /version:%var4% /noprompt "$%var3%" /server:%fnvar%(
%var2%) /console >%srcsrvtrg%
TFS_EXTRACT_TARGET=%targ%\%var2%%fnbksl%(%var3%)\%var4%\%fnfile%(%var5%)
SRCSRVVERCTRL=tfs
SRCSRVERRDESC=access
SRCSRVERRVAR=var2
VSTFSSERVER=http://fusrohdah:8080/tfs/DefaultCollection
SRCSRVTRG=%TFS_extract_target%
SRCSRVCMD=%TFS_extract_cmd%
SRCSRV: source files ---------------------------------------
C:\Builds\2\LocalTestProject\HelloWorld\src\HelloWorld\HelloWorld\Program.cs*VST
FSSERVER*/LocalTestProject/HelloWorld/HelloWorld/Program.cs*18*Program.cs
SRCSRV: end ------------------------------------------------
I observe in the Output window that Visual Studio thinks it has successfully loaded the symbols when I'm debugging my EXE. I do not see a message indicating that it ran TF.exe, however, so I believe it is failing to run this to obtain the source.
I did verify in Visual Studio that I have "Enable Just My Code" UNCHECKED, and "Enable Source Server Support" CHECKED, along with "Print Source Server diagnostic messages to the Output Window".
Question: how do I know if Visual Studio is attempting to run TF.exe to obtain source code from TFS like I would expect?
Aside from that, I'm not sure if my problem is with the build configuration, symbol server/source server configuration, or my approach to attempting to debug using the aforementioned pieces. I will pledge fealty to the wizard who can illuminate my path for me!
Have you tried removing the build server working directories before debugging ? If a debugger can find the files denoted in SRCSRV on disk it will take precedence over getting them with tf.exe (even if they are the wrong version match). Only if it can't find the files on disk or in cache, it will try reference the source server. Because you are performing this on the buildserver, the locations denote a later version of the sources.
I have a project in Team Foundation Server. Every Time I try to either check out and check files in I get the following error.
Team Foundation Error
TF10121: The patch is not found or not supported. Type or select a different path.
I am running from the web based Version of TFS and i am using Visual Studio 2013.
Any one any idea how to fix this pop up its not allowing me to check items in.
Please check your workspace mapping, to what disk path it is mapped. Quick way to do this is to fire up VS 2013, Open "Source Control Explorer" and navigate to the SLN file. Check if it provides a path or says "Not mapped" on top. If it is mapped, try clicking on the path's link and open it.
Using Team Foundation server and BIDS 2008, I receive a screen to check out the dtproj file every time the Get Latest operation is performed.
Steps to Produce:
I have no files checked out after performing a "Get Latest" from solution explorer.
I click to open the solution file .sln from Solution Explorer and the SSIS project opens.
I then receive a "Check Out" screen asking me to Check Out the .dtproj file.
Any ideas how to keep this from happening?
Imperfect answer: How can I prevent BIDS from automatically checking out SSIS packages?
Also related: http://social.msdn.microsoft.com/Forums/en-GB/sqlintegrationservices/thread/654d556f-3826-4fd3-a36a-e7f20a059569
I have been using BIDS 2008 with TFS 2010 for quite sometime but never had the issue that you are facing. Here are the Source Control settings on my BIDS environment.
Some of the other links that might help you:
A project is automatic check outs everytime when i opens the solution in TFS 2008
How to stop Visual Studio from "always" checking out solution files?
This behavior appears to stop if you manually add the .database file to TFS through Source Control Explorer, making sure that the .database filename inside the .dtproj is the same name as the file you add to TFS.
Turns out the .database file is a local 'runtime' type file that Visual Studio creates each time. It is not an actual source file and should not be checked into source safe. What I think happens is that:
This file gets created by VS
At some point someone checks it into source safe, making the file read only in their working folder
Next time VS tries to create the file again. It can't (unless it's checked out) so it creates another one with a slightly different name
Because the filename is now different is changes the .dtproj file that references it. It therefore tries to check the .dtproj file out because a change has automatically been made to it
Chaos and confusion ensues
This is roughly what we did to fix this:
Delete any .database files from source control, ensure that it never gets added back again
Close VS
Backup and delete any .database files from local dev folder
Open VS and get latest
You might get 'this project couldn't be loaded' type errors in VS because the referenced .database file is missing
To get the project loaded, you need to get a valid .database file (these can get corrupted - check the file contents) into your local folder, and edit the .dtproj file in a text editor to point at the valid file
Once you have your .dtproj file working, check it in and have everyone get latest
Make sure no one ever checks in the .database file
Why oh why is it called a .database file when it has nothing to do with a database. When you search online for .database you get...... information about databases, not this annoying VS file.