Highly recommended extension for everyday web dev: - lightweight (no penalty in performance) - provide lots of tool that VS should have by default (code highlight, locate in solution...etc) - flexible: tons of settings to on/off
It would be great to have a template of settings (something like "Web dev settings" or "Mobile dev settings").
Those template settings would make it easier for new users. Anyway, highly recommended.
Hi Camios, All known stability problems have been fixed couple of releases ago, so make sure you're on the latest version. If you're still having problems then do let me know at support@vscommands.com
Ever since i went pro with vscommand i have not been able to properly launch Visual Studio 2010, the program comes up but everything is white, no menues, windows, nothing.
Hi there, There is no binary difference between lite and pro versions so it's unlikely that your problem is caused by going pro. I had no previous reports of similar issue so I'd appreciate if you could contact me at support@vscommands.com. Thanks in advance, Jarek
Hi there, sorry if it's annoying for you. You can easily disable that feature from Tools | VSCommands | Options | Text Editor | Enable Code Block End Tagger
First of all thank you for a great work you do!!! I have just started to use your tool. File structure is great and I already feel it will increase my productivity :)
I have discovered a little bug:
When I cnage a region name and do not refresh the file structure and then click on the node which name was changed VS crashes.
There seems to be a significant delay when grouping items if the option 'Always group files by shortest name' is unchecked before the confirmation dialog appears.
With the option checked, when I select 'Group Items' the grouping will appear more or less immediately; however, if the option is unchecked and I have to click through the confirmation dialog the grouping will take at least 10-15 seconds.
On a related note, how do I turn off 'Always group files by shortest name' if I've already enabled it?
Thanks for reporting this, we'll investigate the delay.
You can bring the dialog back on demand by holding Ctrl when pressing 'Group Items' or uncheck 'Tools | Options | VSCommands | IDE Enhancements | Solution Explorer | Group Items: Always use the item with the shortest name as root' to make it appear every time.
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.
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.
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!
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
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.
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 .