I am getting below error in the Visual Studio 2013 Ultimate when running performance and diagnostics session with Team Foundation Server (TFS). Below are the steps to reproduce:
Get latest from Team Foundation Server.
Create new Performance Session of "CPU Sampling" method.
Launch the newly created Performance Session.
After exiting the session by closing internet explorer or clicking
on "Stop Profiling".
Then I would get below error in the Output Window.
Preparing web server for profiling.
Profiling started.
Launching web server with profiling.
Launching profilable project.
Profiling process ID 9460 (iisexpress).
Profiling process ID 7008 (iexplore).
Process ID 7008 has exited.
Process ID 9460 has exited.
Error VSP1737: File could not be opened due to sharing violation: C:\Users\%hiddenuserprofile%\Documents\Projects\%HiddenPathWithFilename%.vsp
PRF0025: No data was collected.
Profiling complete.
In order to get rid of this error, I would have to clear the read-only attribute of my solution folder which TFS has set. If I clear the read-only attribute then the TFS cannot detect changes in my local workspace with the TFS server. Then I would have to manually check for changes with compare option in TFS and then merge.
Why does this error shows up? Am I doing it the right way?
This error occurs because you have added files to source control that should not be in there. Therefore it is downloaded from TFS and marked as read only.
You should use a .tfignore file. You will have to manually remove all of the files that have already been added. You should not have any /bin/* or /obj/* files for a start...
Then check for *.dll and other binaries, including *.vsp files and remove them from source control.
There are two types of binaries:
References - these should be done using Nuget and never included in source control or added manually.
output/generated - No generated files should be added to source control.
Related
I have cloned code from our company ADO area (someone else's code files) and when loading it in visual studio 2022 I cannot load one of the projects in the solution (unloaded). I get the following two errors:
Error 1: The Web Application Project is configured to use IIS. Could not find the server on the local machine. Make sure the local IIS server has been configured to support secure communications.
Error 2: A project with that name is already opened in the solution.
My colleague who originally wrote the code can clone the code and doesn't get the same issue.
I am also getting a lot of dbl files and debug files automatically populating in the changes and every time I make a change to the code it generates more changes for these kinds of files which is quite hard to then see in git changes what changes are mine and what have been autogenerated.
Can anyone help?! I am new to the Development world, and this is really stumping me!
I have tried going into the user file and setting use IISExpress to false. Was expecting that to resolve the error 1 message but it hasn't.
I have tried putting a gitignore file into my project but it isn't ignoring the files in the changes being auto generated in git changes.
I have a MVC/C# based website. One of the nuget packages being used is a wrapper around PDFium, a non .NET dll. The PDFium dll is included as part of another nuget package and is just a dll that gets copied into the output directory.
The problem I have is that after I have used the website the PDFium dll (ie the non .net one, not the one that is doing the wrapping) seems to get loaded and then locked by IIS. If I then try to do a build in Visual Studio I get an error saying:
Unable to copy file [Full Source Path]. The process cannot access the file [destination path] because it is being used by another process.
A second line in the build error log shows something similar and additionally confirms:
The file is locked by: "IIS Worker Process (28776)"
If I do an iisreset then this will cause that worker process to get killed and thus the copy can happen but I am wondering if there is any kind of better way of doing this. My thought is that all the other DLLs included by nuget packages and similar get copied just fine so maybe there is something a bit more "proper" that can be done to resolve this rather than the slightly heavy handed iisreset approach...
Not sure if any of this will help, but in order to avoid an IISReset, one option is to ensure that the PDFium.DLL being used by IIS is not the one that's copied to your project's target directory during a build. However, if the PDFium.DLL must sit in the same folder as your wrapper assembly (as I suspect it does), then you might not have a good option other than to use IISReset. You could follow advice here (How to restart the IIS Site when re-compiling an asp.net website) to add a pre-build script, saving you from the manual effort.
If the PDFium.DLL doesn't have to be in the same folder as the wrapper and can be registered anywhere on your system, you can try to set that reference's Copy Local property to false so that no copy is attempted. Obviously, this would work only if the wrapper can find the DLL through its registry entry--if it can be registered...
Our builds have been reporting the same error with IIS locking pdfium.dll causing build failure. When I notice it, I use a tool called LockHunter.
When Lockhunter is installed, in file explorer locate the locked file reported by the
error and right-click it.
In the context menu, LockHunter will have added a menu option
"What's locking this file" - select that.
A LockHunter window will appear which reports the file is locked by
w3wp.exe (IIS worker process).
The LockHunter window has an option to unlock the file, select that.
The file is unlocked and then the build works.
Oddly, source control seems to be holding onto files & projects even though I have deleted the artifacts from the Visual Studio Solution (itself). The GetLatest brings down the correct files (even when I delete the underlying artifacts from my workspace by hand). I have never seen this behavior in other servers...in fact...not even my PERSONAL Visual Studio Online behaves this way.
Now...to delete files...I have to delete things twice: once in the solution & once in TFS.
MY QUESTIONS:
Why is TFS holding onto the files in Source Control?
Is this a setting?
How do we fix this?
This is an internal TFS server & I am not the administrator. They are "new" so I am sure I will have to explain the issue at-length.
FOR EXAMPLE:
It's a normal phenomenon. Team Foundation Server uses your workspace to keep track of what files you have downloaded and what version you have of them. The reason it does this is so that it can maintain your files without a costly sync step. With TFS, when you say "Get latest", you only get the latest version of files that have changed since you last got them.
If you delete a file on the server and check that delete in, then when somebody does a "Get Latest", the file is deleted on their local system as well. It's for keeping the local file system in sync with the servers.
If you want to just delete the folder and files locally, there are two way to achieve it, more detail info please refer the answers in below question:Delete Local Folder in TFS
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.
2 projects under TFS Source Control.
DependancyProject.sln
AppProject.sln
With AppProject referencing DependancyProject.
-
The issue I have is with an Installer project in the AppProject.
It has DependancyProject.dll as a 'reference'(?) where it tries to include it in the GAC.
When I try to build this project, to create an MSI to install the App, I get the error
The item $/Assemblues/DependancyProject/bin/debug/DependancyProject.dll is locked for check-out by USER in workspace HIS-PC-NAME.
(The PC in question is not dead and not used)
The dll is not (as far as I can see) checked into Source Control.
The path it references anyway does not exist when I browse through it (no bin folder).
The DependancyProject is refernced by pretty much every project in Source Control, and i've never had any issues with it.
It builds, all the other projects build.
It's just this one Installer Project which doesn't.
And I can't see why it would need to try and modify it anyway.
All it needs to do (I'm assuming) is make a copy of it.
Any ideas here?
Some files are configured as "non-mergeable" in TFS, which means that they'll be locked when changes are pended on them. The default list includes a variety of binary files, including .dll files. Note that this lock applies to all pending changes - including adds.
It's likely that the other developer in question accidentally pended adds for his bin directory - and any binary files in that directory (ie, most of them) would have been locked as well due to being in that unmergeable list.
You will not be able to pend other changes (including an add in a different workspace) while these items are locked. To break this lock, the other developer can do this by undoing the pending changes, or a server administrator can do it using the Find in Source Control functionality in the Team Foundation Server Power Tools.
That said, I don't know why your build process is trying to pend an add on that file.
I had the same problem, and this guide solved all my problems.
The file was actually locked by me, but in a different work space (old computer).
Had to use the tf undo command to unlock the files.
If you are not going to use that workspace again, you can delete it by going to workspace pull down, selecting workspaces, and enabling the check box "Show remote workspaces". you can then select it and remove it.