I've got an app that uses our DAL and when I run it in debug mode (vs2010) and purposely try to make the app crash (for instance, leave the connection string empty of the DAL), vs2010 opens the code for the DAL at the point in which it crashed. Which is ok, but I'm then able to edit that .cs file and save changes, which I don't want. I've verified this by having the DAL project opened in another instance of vs2010 and when I make the app crash and change the DAL.cs in the app and save it, the DAL in vs2010 tells me that the file has been modified outside the project and asks if I want to reload it.
How can I prevent this from happening? The only reference I am using to DAL in my app is the reference to the DLL, that's all.
The AssemblyName.pdb file links the compiled DLL to the original source.
Visual Studio uses this file to display the source code when debugging.
You can delete this file and get rid of the source link.
This will give you a vastly inferior debugging experience.
Have you tried going to "Tools > Options > Debugging > Edit and Continue" and unchecking "Enable Edit and Continue"?
Make the .cs file(s) read-only. If its read-only, you'll be able to see it, but you won't be able to save changes. (Depending on your Visual Studio settings, you might still be able to edit the file in memory, but that seems irrelevant, since the changes you make won't be persisted to disk.)
If you need more fine-grained control (like where you want to be able to edit the source files, but not your testers), you can use access control lists (ACLs). Ask more questions about that on Server Fault.
Yes, you could disable debugging or turn off the generation of PDB files, but that makes it very difficult to debug the code, which is probably the reason why you're purposely trying to make the app crash.
Related
I'm writing a web app using Durandal and it's annoying to have to stop debugging and then restart everytime I add a new controller etc.
You could open 2 visual studio instances
1 for editing (don't debug with it, just edit / save / maintain your project)
A second one WITHOUT the project opened, and have it attached as a debugger to your IE/Firefox/Whatever you use for script debugging.
You can edit the 1st one all you want and the 2nd will only get it's source from live data when you refresh the page so it will be kept up to date. This allows you to change anything that runs in the client side, including adding files, without interupting your debugging session. Of course it doesn't help if you want to add server side compiled elements but there's no way to recompile without re starting debugging anyway.
I found a solution. Basically want to either have IIS Express launched from outside of visual studio or move to full IIS locally.
In VS 2010, I have an asp.net web application project. I made a change to a java-script file and saved it. I then run the application in debug mode and looked at the corresponding dynamically generated java script file. The dynamically generated file still represents the code before i made the recent changes. I tried restarting VS and my computer to no avail... This issue just started happening for no apparent reason.
Thanks,
Right click on solution, and click clean.
I am building an MVC3 application using RAZOR in VS 2010. TFS 2010 is being used for source control.
When debugging the application, it is helpful to be able to modify the Razor view files on they fly. If I open a checked-out view file in VS2010 before I start debugging, I can edit this file while I am debugging. If I open it after I start debugging, it cannot be edited whether it is checked out or not.
Interestingly enough, if I open a read-only file after I start debugging and begin to type in the view to edit it, the file is checked out from source control, but cannot be modified. Additionally, when I stop debugging, I must close the file and reopen it in VS in order to edit it.
Just to clarify, if after I start debugging, I open a view file I already had checked out (not read-only), I cannot edit this file. When I stop debugging, I have to close and re-open the file to be able to edit it.
I have edit and continue turned on, and it works as expected for the controllers and models.
It feels like there is a setting that I am missing somewhere.
Thank you for your assistance.
I've suffering this bug for more than a year. See my question about the problem here: Edit a view in Runtime
This hotfix solve the problem for me.
http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=40811
Here's the official problem reported by the compiler.
Could not load the assembly
file:///Q:\Libraries\v2.0\v4.0.30319\Silverlight.dll.
This assembly may have been downloaded
from the Web. If an assembly has been
downloaded from the Web, it is flagged
by Windows as being a Web file, even
if it resides on the local computer.
This may prevent it from being used in
your project. You can change this
designation by changing the file
properties. Only unblock assemblies
that you trust. See
http://go.microsoft.com/fwlink/?LinkId=179545
for more information.
Now I've been a good programmer and did some research to fix this. Here's what I've tried so far.
Copy the assembly to a FAT32 drive (flash drive) and then back.
Unblock the assembly by hitting the Unblock button in the file properties. (Actually never have been able to get this to work since the button isn't there to begin with)
Use the type command in command prompt
Short of disabling this feature, I'm not sure how to fix this problem. Sometimes it happens, sometimes it doesn't. I should mention that the Q: drive is a network drive on a separate server. My machine is running Windows 7. The assembly Silverlight.dll is a library created by some of the developers here at work. We just placed it on a shared network drive so everyone could find it easily. Even if I log onto the server and look at the file properties, there isn't a Unblock button like in all the tutorials I've read.
Copy the file onto your local drive (maybe somewhere into the solution/project dir) and then right-click the file in Windows-Explorer.
In the file properties window you will find a warning that this file comes from a remote computer and a button to permit access (In German "Zulassen"). Click it! Now rebuilding your Silverlight application will work.
Screen shot:
copy it local (I create a Libs folder for all dlls copied locally).
add it as a reference to your project.
in windows explorer right mouse click on the dll and click the UnBlock button on the main tab.
build Silverlight project.
error goes away.
Wondering if anyone has a solution to this 2010 bug. I have a project that built fine in Visual Studio 2008 that wont build in 2010 because Visual Studio is holding on to the dll after the application is run ONLY if a designer window is open. I created a really light weight project that shows this problem. If you create an application then create a lib dll. Put one form in the dll, open the form in design view and then run the application. It will run fine, then close the app, go to the code view of the form in design view, and change the code ( I just renamed a single variable) then try to recompile you get the following:
Error 1 Unable to copy file "obj\Debug\customlib.dll" to "build\debug\customlib.dll". The process cannot access the file 'build\debug\Customlib.dll' because it is being used by another process.
If you run Process Explorer and search for the dll, the only process holding the dll is devenv.exe!!!
I have done a ton of searching on this problem and have found similar issues with older versions of Dev Studio where people were able to just add a pre-step to move the locked dll to another name (.locked) and build. Well that works the first time, but the next time you run then edit you are locked out of both the current dll and the one you moved to .locked, so unless I am willing to add code to randomly generate a name for the locked dll, this wont work for me (I don't want my debug directory size to grow with files never getting deleted.)
I have only found one workaround and if you are in this same boat this is what I have to do to edit and run. I make sure EVERY design view window is closed BEFORE I ever run my project in the debugger. If you close all the open design view windows devenv.exe will not hold the dll.
Does anyone have a better solution to this problem?
I'm not sure whether this will work for you or not, but this similar question if you have this line in AssemblyInfo.cs:
[assembly: AssemblyVersion("2.0.*")]
changing it to:
[assembly: AssemblyVersion("2.0.0.0")]
will solve this isue.
The Visual Studio add-on "VSCommands" claims to have a fix for this problem. I've not tested it yet, but it also claims to have an in-IDE stackoverflow reputation tracker which intrigues me :)
Your "Close designer before debugging" workaround seems to be working for me (so far), for which I'm very grateful. It was beginning to get to the stage where am large part of my day was spent in the following workflow...
F5
loud expletive
ALT F4
WIN 3
waits impatiently...
F5
I have had the same problems for a long time and then suddenly they disappeared. I realized that the source of the problems was initializing code in the constructors of WCF services and WPF controls. After cleaning the constructors from any dependencies to other assemblies everything has been fine.
So my suggestion is: Clean your constructors.
In WPF it is possible that inserting:
if (DesignerProperties.GetIsInDesignMode(this)) return;
or similar will have the same effect.