I am writing some C# code with visual studio and I have a weird behavior with brackets. Let's see an example.
First I write this code:
Then when I add a single bracket with AltGr + Shift + [ I get this:
The entire class gets selected. How can I avoid this? The issue came out after the update to the latest version.
I am using the latest version of everything. I have VS 15.8.0, C# 7.3 and the .NET 4.7.2, any idea?
Please note that some times, after a { the entire class gets selected and I am not able to type the closed bracket }.
This happens when I write C++ as well. (like a new Console App). I have tested it right now in an empty project and the issue is here on C++ as well (VS 15.8.0, C++17). I have added a random c++ function to a library of mine and I have this behavior like in C#!
Possible solution
When I get the entire text selected, I press esc and the text gets deselected (plus the cursor is still at the right place). This is annoying AND this wasn't a problem 2 hours ago (when I had the old version).
I have an Italian keyboard and I can reproduce this behavior after the update. The fact is:
AltGr + Shift + { adds an open bracket as expected
AltGr + Shift + } selects the entire declaration of the class/struct in which you are creating the method
I wasn't able to find the keyword map that generates this behaviour (under Tools > Environment > Keyboard).
A solution may be the following: be sure that you have the automatic bracket completion enabled (which is already, by default) and type only the open bracket. In this way, when you type { you automatically get the closed bracket.
What if you need to type a } then? Well, you can use Alt + 125 and you'll get the close bracket (open bracket is Alt + 123.
Related
I'm using DotNetBrowser and currently when I close my application I get the error System.InvalidOperationException in DotNetBrowser.dll (Channel is already closed).
When attempting to debug why this was occurring, I opened up the exception's details and found something strange. The StackTrace, TargetSite, DeclaringType, ReflectedType, etc., are all written backwards.
Is this because DotNetBrowser wrote their code backwards? Is this a bug with Visual Studio? What's going on?
Dot net adds RTL markers in the text.
copy the text in a text editor(notepad or so) hit CTRL + Home, type a ' single quote, CTRL + END type: '.split('').reverse().join("") (It will appear reversed but will still do it's stuff correctly)
Open a browser, hit f12, move to console and paste the the entire document and hit enter.
so in this case:
console.log('egassM.segassM.CPI.slanretnl.resworBteNtoD('.split('').reverse().join(""))
And then you have the readable message in your console.
This is the worst type of security.
You may notice that some entries are written backwards, some are messed up and some other entries are missing.
The release build of DotNetBrowser is obfuscated and protected, that's why the stack trace entries related to its internal logic are unreadable.
I hit this odd behavour yesterday in Visual Studio 2015 where I was making a string that started and ended with double quotes. In stepping through the code I hovered over the result to see the contents and there were back slashes in the string - what! (see image below). Cutting a long story short, I figured out the debug view of the variable is displaying with the escaping backslashes - which in my opinion is misleading.
Does any one know if there is a way to disable this in Visual Studio so that it just displays the value as either ""bob*"" or without indication of the string type "bob*" ?
P.S. Yes I know, it seems a bit newbie to be using VS for years before noticing this behavour. Also the image is not showing our production code :)
This is expected. Because you are under debug mode you are given the dev version of the string.
To get a user friendly version of the string (actual value without slash) you just have to click on the magnify glass icon on the left
I am developing a new version of a Visual Studio extension. In the old version, the hotkeys were stored in the registry and I would like to import these settings into the new version of the software.
The new version uses .vsct format for defining menu commands and you can assign the hotkeys in the .vsct file. However, I can't use this mechanism, as I would like to import the user settings from the registry, whiles the .vsct is a static description.
When my VSPackage is initialized, I can read the old hotkeys from the registry, but I have problems assigning them to my menu commands defined in the .vsct file. I can get a hold on the OleMenuCommand interface and OleMenuCommandService, but they have no property where they can accept key bindings.
How one can assign hotkeys to menu commands programmatically?
A clunky workaround would be that the installer imports the hotkeys, writes them into the .vsct file, compiles the file and puts the .cto into the MyPackage.Resources.dll during the installation. But I'd rather not resort to this...
Though I define my commands through the .vsct file, I still can access them via the EnvDTE.Command interface.
// The commandGuid has to be the same GUID you use in the .vsct file, HOWEVER, you have to include the braces here
Command command = dte.Commands.Item(commandGuid, commandId);
command.Bindings = new object[] { "Global::Ctrl+Alt+Shift+1" };
It works. It is saved and remembered the next time Visual Studio starts up, so there is no need to import the old hotkeys every time.
Since I'm not allowed to comment [despite my 50 years of systems-level programming experience, including 3 books for MS Press :( ], I have to ask this way for Shakaron to post some more of his code. I added a short tree of menu commands to the VS 2015 Tools menu (1-4-1 elements). An enumeration of dte.Commands didn't show any of them. Calling Commands.Item with a string (or an "object" to which I'd assigned a string) containing the GUID, both with and without {}, generated an invalid argument exception.
So, either the EnvDTE80 interface is incredibly fragile, the documentation is wildly wrong, or else Shakaron's solution has some more magic that we haven't seen yet. And I was so hopeful that this would be the last piece of my puzzle...
Answering Shakaron's questions:
I used the .vsct file to add 1 menu with 3 commands and 1 submenu, which in turn had 1 command.
Calling Commands.Item with a guid and an index argument caused an apparently identical invalid argument exception. I was able to enumerate the collection, but my commands were not in the set.
I also couldn't compile your code for the right-hand-side of the Bindings assignment. But, of course, I didn't get that far because I couldn't find the command item in the first place.
There has to be a version dependency at work here. I don't doubt that your code worked a year ago, but I ran into the problems I described using a fresh-out-of-the-virtual-box copy of VS 2015 running on Win 10.
In certain cases typing an opening square bracket results in nothing at all. In particular when I want to type them on a variable in the right side of assignment expression:
arr[i] = arr
So I cant type, for example:
arr[i] = arr[9]
It has something to do with Resharper. However, turning of autocomplete and stuff doesn't seem to solve it. Anyone familiar with this problem?
I had the same issue the first time I insalled Resharper.
Look under Tools > Options > Environment > Keyboard to what is bound to Ctrl+Alt+^ (equals to AltGr+[ since I suppose you work on an AZERTY keyboard). Easiest way of doing is by just entering it as a new shortcut.
Remove or rebind the shortcut that comes up and you're good to go.
I had the almost same issue in Visual Studio Express 2012. I couldn't write theese -> } <-.
(Same problem as you, #hazard)
After reading #Bart's answer, I saw that Ctrl+Alt+0 was connected to something called "View.ViewCode". So I removed that shortcut and it worked.
What's weird though, is that I COULD write }s during the first few hours I used VS2012 after installing it.
I have a number of generated .cs files (originating from WSTL files). ReSharper isn't happy and I'm getting so many errors/warnings that its tough to separate the signal from the noise.
Is there a way to work around this? Can I suppress all the warnings/errors in an easy way?
My goal is to keep from (or minimize) changes to the generated files.
Turn code analysis on/off => Ctrl + Shift + Alt + 8 (with Visual Studio key bindings; otherwise it could just be Ctrl + 8 )
There are different ways to mark code as generated in Resharper the documentation explain them all but i guess that for your case changing the name of the files to match the default *.generated.cs would be the simpler.