Visual Studio 2015 locks DLL during debugging - dll

I have 3 C# projects A, B, and C. Both A and B reference C. The references to C from A and B are set to "Copy Local" implying that after C is built to C.dll (in the output directory of C), it is copied to the output directory of A or B (whichever is being compiled)
I have 2 solutions, SA and SB. SA contains A and C and SB contains B and C. I launch 2 instance's of Visual Studio 2015. I open SA in one instance and SB in the other.
I am finding that if I Start Debugging (F5) A from SA, and then (while A is still debugging), make a change to C from SB and attempt to compile SB, I receive a compile error stating that C.dll can not be over-written because it is in use by another process (the instance of devenv.exe which is running SA).
This does not make sense to me because after compiling C to C.dll and copying to the output directory of A, Visual Studio should release the lock on the file.
I have verified (via the Modules window in SA) that the version of C.dll loaded is the one which has been copied to the output directory of A.
This started occurring yesterday when I began using Visual Studio 2015 (instead of Visual Studio 2013).
Does anyone have any ideas? My current solution is to run SA via CTRL-F5 (start without debugging), but this becomes annoying when I want to run SA and SB in debug mode simultaneously.
Thanks.
UPDATE
I did some research into why the "Edit and Continue" feature could cause the described behavior, and according to this page https://msdn.microsoft.com/en-us/library/ms164926.aspx> Edit and Continue allows one to make source code modifications while in a debugging session and have the results take effect without stopping debugging, recompiling, and restarting the debugging session (what a gnarly problem that must have been). With that feature enabled, Visual Studio might be required to recompile any dependent DLL's at any time which explains the lock.

I had the same problem. I changed my VS2015 settings and it seems the problem is gone:
disabled Options\Debugging\Edit and continue
-Options\Sourcecodemanagement from TFS to none-
-disabled Options\Debugging\Diagnostictools while debugging-
Not sure wich one caused the locking, but i suspect the diagnostictools wich I did not have in VS2013.
(The settings names I translated from German to english, don't know if it is exactly how they are called in english VS version.)
Edit:
As researched by Shea it was the Edit-And-Continue feature that locked the DLL.

in my case this was "Panda free Antivirus" Who was watching on the dll of the "C" project and this caused the error: "the process cannot access the file because it is being used by another process"

I had the same problem and none of the other recommended solutions I came across while searching the interwebs worked for me. Finally after "repairing" Visual Studio 2015 Enterprise, I tried launching Visual Studio in safe mode: devenv.exe /SafeMode
In safe mode I was able to finally build my solution, and when I started again without the switch, I was prepared to shut off extensions one by one until I found which one was the culprit. Luckily that was unnecessary and subsequent builds went off without a hitch.

In my case, the .pdb file was locked. This is not the same as the .exe getting locked as it should be when debugging.
Assuming it's just the .pdb, simply move it to a new folder (I dragged and dropped). Oddly enough, it cannot be deleted, but it can most certainly be moved! Once the .pdb file was gone, the assembly was able to compile again.
The alternative solution (and probably the least convenient) involves closing out of the project entirely, then opening it again (the .pdb file magically unlocks!).
Edit:
After happening a second time, moving the file did not work; it appears restarting the project is the only reliable way to go.

Related

VB.net .exe cannot be run from another computer. Missing assemblies for ClosedXML

I must put this program into production today, and I can't get it to run independently.
In the program, I have included NuGet package "Imports ClosedXML.Excel" and use it to create spreadsheets. When I build my executable, and try to run it from another computer, it cannot find the ClosedXML and Documentformat.OpenXml assemblies.
I checked in References that "Copy Local" was = True for ClosedXML and Documentformat.OpenXml, but it's not working. I found another website that mentioned Global Assembly Cache, and that if the dependency is in there, it will not be included in the Build .exe.
I am running Visual Studio Professional 2017. I am in over my head on this one, so if you have answer (and I hope you do), please try to provide it in elementary terms I can understand.
Sometimes issue is solved by individually adding application files inside the following menu
Go to Publish-->Application Files
Select Show all files
Under Publish Status
Set the files you need to Include [not include(auto)]

VS2012 Compiler randomly tells that output file can't be written

I am compiling a bigger VB.NET project using VS2012.
Randomly, but very often after having run my project in Debug Mode, I get the error
"The output file <mypathhere> could not be written. Permission denied."
I have also tried using MSBUILD to give me more details about this error, but it didn't help.
Also, I have tried disabling the Hosting option because I thought that this might be the cause, but it wasn't.
I used ProcessExplorer to find out which process might have locked my file, but it didn't show anything.
Does anybody have any more ideas?
When I try to set the application's output folder to not-writeprotected using the Windows properties dialog, I get the "Changing attributes denied. Permission denied." error on the output file.
Thank you very much!
There are a couple of reasons why this could happen
An instance of your program is currently running hence Visual Studio can't write over the file. Next time this happens check and see if any instances of your program are running in task manager.
An anti-virus program has a lock on your file to analyze it and prevents VS from overwriting it. Try excluding your project director from analysis and see if the problem dissapears
The solution is to activate the Application Experience service in Windows. This is a known MS bug.

How to write the sample COM Server in Visual D

I'm struggling to get a simple COM Server running in Visual D 2010. These are the steps I did so far:
Clean Visual D 2010 solution of type Dynamic Library (DLL)
I've copied contents of dserver.d into dllmain.d
I've copied file chello.d and dserver.def into the solution's source folder, as well as advapi32.lib and ole32.lib from the <D install dir>\dmd2\windows\lib.
I've added the copied file into the solution by right-clicking the project in the solution explorer and Add->Existing item...
Renamed file dserver.def into dll.def, overwriting existing project's file.
Applied a patch to the chello.d and dllmain.d (originally dserver.d) as written on this forum thread
Build Debug. No errors.
Calling regsvr32 COMServer.dll returns these four message boxes:
then
then
and finally
I am still unable to access the COM object from VBA. And referencing the DLL directly (by Browse... button and pointing to the COMServer.dll) fails with "Can't add a reference to the specified file."
I took another look at the forums and the problem with the samples seems related to TLS on Windows XP. I posted a (somewhat hacky) solution to it here:
http://forum.dlang.org/thread/mqoxluonyjdtjxauaxnl#forum.dlang.org?page=2
I can't provide you with a working answer. It looks like this was a year ago, I was trying to get an example of using a COM server working. This uses Juno (not 64bit ready), has nothing to do with Visual D, and most importantly I couldn't get to work. The issue I hit was related to registering the server ("side-by-side configuration is incorrect").
My qualifications for COM are all there in the history of Juno (so not much of any). If you're more familiar with COM you may get further, if it doesn't compile for the latest DMD let me know (2.064 isn't out yet anyway).

Team Foundation Server - Committed files appear hidden for other TFS-Members

Since some months, we are using TFS 2012 with Visual Studio 2012 and until some weeks we didn't notice any problems during checking in/out. Furthermore, we are working on a ASP.NET MVC4 project.
But recently, we noticed that if Person A checks in new files (f.i. .cs or .cshtml) and Person B does "Get latest version", then he receives those files but they are hidden for some reason. So we have to do "Include in project" manually every time. This happens to any of us.
Neither I have direct access to the TFS configuration nor did I change my Visual Studio settings. Thus, it is really strange that this happens for no known reason.
Do you have any ideas what I should try or check?
The only time I have seen this kind of behavior is when someone checks in the files, but not the corresponding .csproj file. The .csproj file contains the definition of what files are included, so for the solution to build with the new files, the .csproj file must be checked in as well.
Note that it may be necessary on occasion to do a "Save All" before the changes to the .csproj file are committed.
I would recommend checking the .csproj file of the last few check-ins that have had this problem. I've encountered this any number of times when one of my co-workers "Excludes this file" from the project because they don't understand why something isn't working. They forget to re-include it in the project and then check everything back in. The project file doesn't contain the files that were excluded.

How to disable warnings in Visual Studio for a Visual Basic Web Deployment Project

For our VB.NET websites we use SVN for Source Control and CruiseControl.NET for continuous integration.
To use the SVN build number in the compilation by CruiseControl.NET we need to use Web Deployment Projects. We then replace in the configuration file the Version field with this variable from SVN Labeller
$(CCNetLabel)
This works great but my problem is that this variable causes warnings in Visual Studio for the solution. I'm working to remove all warnings and am left with just these two:
Warning 1 The version string specified for 'AssemblyFileVersion' in the project file is invalid. C:\MyProject\MyProjectDeploy.wdproj
Warning 1 The version string specified for 'AssemblyVersion' in the project file is invalid. C:\MyProject\MyProjectDeploy.wdproj
I have searched for ways to disable certain warnings but they all reference Windows projects not web site/deployment projects which do not contain a Compile tab.
I found information on using #pragma warning( disable : 1000 ) but it appears this is for C++ only and not VB.
It's not a show-stopper but is annoying the hell out of me this lazy Friday afternoon, any help would be appreciated - if reputation sharing was working yet I'd offer someone 20 of my rep for a workable solution :) at least....
It is possible to ignore errors, it is just in a weird place for vb.net.
Open the .vbproj file with notepad or an equivalent and find the <NoWarn> tag and add the id of the error there.
in a default 2008 winforms, I have these warnings already ignored.
<NoWarn>42016,41999,42017,42018,42019,42032,42036,42020,42021,42022</NoWarn>
If you used Nant in your build script you could just have it re-write the version prior to compile, and you wouldn't see the warning when you are working on your local machines.
Had a very similar situation with an old VB web project, and we did not want to add the #pragma blocks all over the code calls. For some reason, adding the lines to the <NoWarn> fields did not make Visual Studio builds ignore/suppress the warnings.
However, I found a different approach. By adding this in the .vbproj file after the <NoWarn></NoWarn> area ignored the obsolete warnings in VS 2017:
<DisabledWarnings>612;618</DisabledWarnings>
Common MSBuild project properties
Description of configuration setting:
DisabledWarnings Suppresses the specified warnings. Only the numeric
part of the warning identifier must be specified. Multiple warnings
are separated by semicolons. This parameter corresponds to the /nowarn
switch of the vbc.exe compiler.