VSCommands for Visual Studio 2010

Hi

The output window colouring seems to forget the settings that I set in it. Has anyone else noticed this? Every time I start VS2010 I have to go into tools | options | fonts and just press ok, and it then (mostly) sets the colours to the ones I have set. This is most apparent with the 'highlight current line' feature, as it always reverts to the white-ish colour.

I use a dark colour scheme and some of the colours that appear as highlighting have a white background. For example, urls in the output window appear as blue foreground and white-ish background. Can I change the colour of these items?

Also the NuGet/NuPack package manager console seems to highlight the current input line (like the code windows do) but I cannot find where to change the background colour of that line highlight as it is difficult to see.

Can these settings be set in the options?

Thanks

Matt

Sorry! My mistake, VSCommands does not do the current line highlighting so I'm barking up the wrong tree there! However there are still issues with the colourisation of the build/output windows. With a black background things like the url highlights are in a blue foreground and white background and I can't see a setting for that. Also when I set the background colours of the VSCommands.BuildOutput.xxx settings they seem to revert back to default a lot of the time.

Thanks for reporting this issue.

The way urls appear in Visual Studio is controlled by VS itself and VSCommands does not change the default behaviour (at least not directly). Unfortunately, while the default behavior for Text Editor can be changed from Tools | Options | Environment | Fonts and Colors | URL Hyperlink, there seems to be no way to change for Output Windows. We will investigate the possibility of a workaround for this behaviour though and will post an update here.

Thanks,
Jarek

Every time I Startup Visual Studio 2010 I get an error prompt at Startup of Visual Studio 2010.
 
Version Problem occurred on:
--------------------------------------
1) DPack v3.0.1 for Visual Studio 2010 - problem occured on this version
2) DPack v3.0.7 for Visual Studio 2010 - this one as well, was installed today

Windows 7 64-bit Enterprise, automatic updates on, MS Security Essentials, Visual Studio 2010 Ultimate.

The following works fine (from CMD):
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE>devenv.exe

The following crashes:
C:\>"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe"

The crash details are the generic "Microsoft Visual Studio has stopped working" etc, no real info

If I click "Debug" and choose to debug with a new visual studio 2010 instance, a new instance of visual studio is opened successfully, displaying:

> Unhandled exception at 0x01c958a0 in devenv.exe: 0xC0000005: Access violation.

I have isolated the issue to VSCommands, I am guessing the latest version since it never happened before. I don't know where I can download an older version to check.

UPDATE - now it always crashes, full path or not 

Thanks for your help !

Thanks for reporting this issue.
Does the crash occur during VS startup, shortly after or during execution?
Also, is there anything reported in event viewer? It would be very useful if you could run 'devenv.exe /log' and send us contents of C:\Users\<userName>AppData\Roaming\Microsoft\VisualStudio\10.0\ActivityLog.xml to support@vscommands.com

We had another report of similar issue on Xp 64 bit machine and managed to reproduce it internally.
VSCommands 3.6.3.4 contains the fix which should help with your problem too.

Yes, the issue appears to be fixed !

Thank you very much

I can't install the new update and even remove the current one on my VS2010 Ultimate on Win764 bit, the error is "VSCommands cannot create a file when that file already exist".
Ideas?

It seems that Extension Manager doesn't always delete all files when upgrading to a new version and leaves extension in a corrupted state.

As a workaround you can try to delete all traces of VSCommands or DPStudio folder in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions and reinstall the extension.

Well looks like Debug as another user needs some more attention. Thank you for fixing the password field, however now I am getting a page that states No Source Available. I also added the code to wait until the debugger had attached and I got nowhere.

Hi Steven, 
When you get the 'No Source Available' in Visual Studio, try to press Break All (Ctrl Alt Break) and Continue (F5). Next time you press Break All it will break into code as expected.

Alternatively, when using the code to wait for debugger, you can set a break point one line below that loop and debugger should pause on that line next time you debug as different user (instead of showing No Source Available).

We are currently investigating what causes No Source Available to show in the first place and should come up with a fix shortly.

An update has been release which fixes No Source Available issue.
Thanks for reporting it.

Using version 3.6.3.0 with the lite version I am unable to turn off some features.  

For  example when I click on the Enable check box under "Open Command Prompt" nothing happens.

Is this a bug?

Hi Matt,

Thank you for letting us know about the problem, we'll try to reproduce it and will post an update here.

As for the lost preferences after upgrading to newer version - we were able to reproduce it and are currently working on a fix.

Thanks Again!

We have just released an update with fixes to these bugs.
Thank you for reporting them.

I just want to say that I love vscommands and I use them heavily. I have some strange activity though. I have been using Debug as different user and for some reason it quit even trying to debug.


------ Build started: Project: , Configuration: Debug x86 ------
//files
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

In this VScommands output I get this:
Exception has been thrown by the target of an invocation.,    at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeType typeOwner)
   at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeType typeOwner)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at —.–.(Object target)
   at DPStudio.VSCommands.Features.MenuCommands.DebugAsDifferentUserCommand.—()
   at Œ.ˆ.(). . Data: Key: resourceEntryKey, Value: DPStudio.VSCommands.Features.Views.DebugAsDifferentUserView.xaml

Thanks for your time,
Steven Combs

Sorry that post was horrible let me clarify.
Whenever I hit Debug as different user it doesn't pop up the authentication dialog box like it used it. It seems to just build the project and then its done. I tried uninstalling vscommands and re-installing and this didn't fix the issue.

Again thanks for your time,
Steven Combs

Hi Steven,
Thanks for reporting this issue.
We were able to reproduce it and the fix will be released within next two days.

Awesome! Thanks guys!

Whenever I run the Debug as another user, it uses my supplied credentials and runs correctly. However, when I want to actually debug something and put breakpoints in my code it doesn't even stop at the breakpoints I have put in. A matter of fact it seems as if it just overlooks all my breakpoints and runs the executable. Has anyone else had these problems and am I doing something incorrect? Any help is greatly appreciated. 

Hi Steven, Unlike 'debug as admin' and 'debug as normal user', 'debug as different user' doesn't attach debugger straight away, i.e. there is a short delay between a moment when application starts and a moment when debugger is actually ready to stop at breakpoints. This has to do with security changes in Vista / Win 7.

If your breakpoints are set in the code that executes right after application starts then you may consider adding this lines of code at the beginning:

#if DEBUG
  while(!Debugger.IsAttached)
  {
    Thread.Sleep(5);
  }
#endif

It will stop execution of your application until debugger attaches itself.
All breakpoints set after this should now work as expected.

Thank you very much I will give that a try. Also, will there be a password protected text box coming up in the future. I could really use this debug as another user in a corporate domain environment; however, my use of it will be discourage since the password text is not ***** like so. 

Thank you very much for the quick response.

Thank you for your suggestion,
Masked password textbox will be ready for next release.

i have been using VSCommands since very early days (switch from PowerCommands) -- and it WAS a great add-in. 

however, is there anyway to default new feature to be OFF by default ?

Because in the last couple months, it has been bloated with features only seems to only work with specific occasion -- like custom color output, apply fix, drag-n-drop warning... etc. And it starts to change VS launch behaviors with modal dialog, new tab....

Worst is, it updates very often, and unfortunately often the updates reset some of my preferences. So my VS has been 'changing' every week in the last 3 months, and is get somewhat anonying...

thanks

Most of other plugin doesnt seems to be as aggressive 

Thanks for your feedback,
At the moment there is not way to disable new features by default, but you can disable automatic updates and only get latest version when you are ready.
There is a thread on our feedback forum where you can find detailed description on how to do that [ http://vscommands.uservoice.com/forums/62899-general/suggestions/1074491 ]

As for other features that you mentioned such as custom color output or apply fix - these are available in PRO version only. You can still use them for a limited time with VSCommands Lite but after some time they will not be available anymore. More details about availability of features in each version are at http://vscommands.com/feature-comparison .

We are trying to get the right balance between which features remain free and which are part of premium package and actively continue development work in both directions. We are also open to any suggestions, so please feel free to contact us at support@vscommands.com or our feedback forum vscommands.uservoice.com .

Is there any way to turn *off* the automatic update feature? I would much rather update this myself rather than having it be automatically updated.

In latest build you can add this value to registry and it will stop automatic updates:

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\vscommands]
"DoNotAutoUpdate"=""