I have a strange problem, Visual Studio changes the windows proxy settings when executing a test.
Do you know if it is a normal behaviour and how to avoid it?
thanks in advance.
Related
I'm trying to debug a VBScript. I installed Visual Studio 2017 Community edition, but whenever I run my script (with a stop placed near the beginning of the script), the Just-in-Time debugger does not pop up and my scripts continues.
I've looked at the following, and nothing has helped:
Just-In-Time Debugging in Visual Studio
I've enabled it in Internet Properties.
I've enabled "Managed", "Native", and "Script" in Tools\Options\Debugging\Just-in-Time in Visual Studio 2017.
All the registry keys listed in the article are present in the registry.
I was able to follow the article C# Console App example. It did (although with variable success) eventually get into the debugger.
Visual Studio 2013 and VB Scripts
I tried debugging in the manner detailed here, but it never stopped at the stop or any of the breakpoints I set up.
The only thing I can think of is maybe the values in the registry are incorrect. The MSDN article didn't explicitly mention what the values should be.
Have other people tried using Visual Studio 2017 for debugging VBScripts? I've had luck using 2010 and 2012 at my work computer, but sadly I can't find downloads for those versions of Visual Studio for my home computer.
If anyone has any ideas, please let me know.
If you run your VS as the admin, and enable the Script debugging under TOOLS->Options->JIT debugging, how about the result?
I used the VS2017 Enterprise version before:
Visual Studio 2017 debugging vbscript
Or check the workaround in this feedback which is similar to this issue:
https://developercommunity.visualstudio.com/content/problem/30845/vs2017-script-jit-debugging-is-not-working.html
We are receiving an unexpected error when using our VBScript external debugging tool. We used this link in the past to create the external tool:
Visual Studio 2013 and VB Scripts
It has worked fine in VS2013 when we created the tool. Well, we moved to a new machine and now this tool will not work. We receive the following error asking us to register the PDM.dll or it is missing, which we have done. I'm assuming it is a configuration issue of some sort either in the Visual Studio 2013 or elsewhere. Would anyone have experience with this or could offer a suggestion?
Error:
"The script debugger failed to connect to the target process. The correct version of pdm.dll is not registered. ...."
I know this is common error but we have tried the common fixes that we are ware of.
Thanks!
When I loaded VS 2012 (with VS 2013 still installed), somehow it fixed the issue. Both 2012 and 2013 can debug VBScripts with use of the External Tool created for VBScript debugging. We had this issue before in the past, on the previous machine (i.e. PC), it was just the opposite fix. VS 2012 wouldn't debug VBScripts with the External Tool created, but after loading VS 2013 it worked. Somehow, the second installation changes the configuration which impacts both versions, resulting in the VBscript target connection to work.
I am having trouble with Visual Studio 2012. We have windows service written in VB.NET and we have one unit test we use to initiate debugging process for that service. Problem is that sometimes Visual Studio detaches from debugging of service and instead of breaking execution, service just continues execution until everything is done.
How to prevent this form happening? It's very annoying and destroys prepared test cases.
Solution is to install Visual Studio 2013 with Update 5.
Also to note, release version of VS2013 has a bug which is causing application rebuild every time you try to run/debug application (even though you didn't change anything).
I have the problem that Visual Studio 2013 crashes when I lock the computer or start another instance of Visual Studio.
I use Visual Studio 2013 with latest patches applied. I always start Visual Studio as Admin.
This seems to only happen with a certain big solution. This problem did not occur to me with other solutions.
I tried to delete the solution and make a clean checkout from TFS, but Visual Studio still crashes.
I know this is not much information, but do you have any idea how to fix this or how to what else I could check?
Additional Information: This still happens even with Visual Studio 2015 on a fresh Windows 8.1 installation...
Here's the error:
Use the following steps to solve the issue:
Source: http://resharper-support.jetbrains.com/entries/24765142-Visual-Studio-with-ReSharper-is-freezing-and-or-crashing
I would copy the solution with quotation but as you can see, there is a lot of text to edit.
Start Visual Studio using the /log switch. Then check the created log file for warnings and errors:
%APPDATA%\Microsoft\VisualStudio\11.0\ActivityLog.xml
If you use a Web Browser to view the file, it will be nicely formatted, due to the accompanying xsl-sheet.
I had a working build script locally that I could build and publish a VS 2012 WebApplication project with just fine until I installed Visual Studio 2010, I don't get seem to get any real errors but it does not publish at all now it just builds and shows success no errors, I do see this in the ms build log :
Target WebPublish in file C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
I know I am still using the correct version of MSbuild but why is it now trying to use the wrong targets file? Would running the Visual Studio 2012 repair fix this? Is there some registry setting or config setting somewhere for this?
I have spent hours trying to track down why this script that worked before and hasn't changed now doesn't work locally but it is still working on my build server just fine, which made me think of what has changed on my machine since I last ran this build fine locally. Any help or suggestions as always is greatly appreciated.
Thanks!
The easiest (though lengthy) solution will be to repair visual studio:
Repair Visual studio 2012 from the Windows' Programs and Features window
Re-apply Visual Studio Update 4
This will ensure the latest bits are back in the place they should be.