17 December 2007
One Line - Moving Code Around
Holding Ctrl-Alt-Shift and pressing arrow keys moves code around. It can move members up and down, reorder parameters in place, move statement within a block, move statement out of block or into block, and move XML tags around. Note, that it is just textual editing, it doesn't check if such move would be valid or fix any references.
16 December 2007
One Line - Naming Style
If you configure your field naming preferences in options (Options / Languages / Common / Naming Style), ReSharper will derive better names for properties and other entities when generating code.
12 December 2007
One Line - Create File From Template
You can use Alt-Ins in Solution Explorer to create file from one of your File Templates in the current folder.
Feature of ReSharper 3
Feature of ReSharper 3
11 December 2007
ReSharper and Visual Studio crash on x64
For those who experience problems running ReSharper on x64 machines, here is the bug description on Microsoft Connect.
Updated 13 Feb:
Deep in the comments to the aforementioned request there is information about how to obtain hotfix:
And also:
It turns out that this crash is the result of a bug in the Wow64 layer of Windows x64 (XP/2003 – it has been fixed in Vista x64) and only manifests itself when another app globally hooks all Windows messages.
We are currently working with the Windows servicing folks to get a hotfix produced.
Updated 13 Feb:
Deep in the comments to the aforementioned request there is information about how to obtain hotfix:
If you are experiencing this issue you will need to contact Microsoft Customer
Service & Support (http://support.microsoft.com) and ask for the Windows
Hotfix with ID 947841. If you have any difficulty in obtaining the patch
ask the CSS representative to contact me (Sean Laberee).
I am also pleased to announce that we have created a workaround in VS 2008 SP1 which eliminates this problem and the need for the patch. That workaround is queued for checkin to our build process and will be available in the Beta of the service pack.
And also:
A quick update on the windows patch. I've confirmed with our support team that if you call in for this hotfix you will not be charged. They will set up a "Hot Fix" case for you. I've also received a report that there was some confusion as to whether this fix is for Win2003 or XP. I've confirmed that this fix does in fact apply to both releases.
28 November 2007
ReSharper Club - Are You In?
Well, not really a club, but we thought you may wish to have cute ReSharper banner on the side bar of your blog, or project site, or may be print it and put on the wind-screen of your Porsche :) I have one right here, in my blog! Ah, well, I mean banner, not Porsche...
Want it? Go to The Banner Builder page and assemble it as you like. Don't forget to put the result on your website!
Want it? Go to The Banner Builder page and assemble it as you like. Don't forget to put the result on your website!
22 November 2007
ReSharper and Visual Studio 2008
Since there is a lot of buzz about Visual Studio 2008 release, I thought I would stand and say about ReSharper in relation to this fact.
Released version
ReSharper 3 can be installed with Visual Studio 2008 and works fine, unless you are using C# 3.0 new features, like lambdas, LINQ, extension methods and such. This constructs are not parsed by ReSharper 3, which was developed to support C# 2.0 only. It is not only highlighting which doesn't support C# 3.0, it is all the core and code intelligence. For example, rename refactoring will not find usages of extension methods and will not update them.
There also could be some glitches, even if you don't use new C# 3.0 constructs. This is due to the fact that C# 3.0 compiler is always used in Visual Studio 2008 C# projects, regardless of target framework. It it is not widely discussed, but changes in language are wider than just several new features. There are differences in type inference in generics and candidates lookup for binding, to name few. If you happen to hit this special cases, ReSharper could behave incorrectly.
If you are really-really going to immediately jump C# 3.0 wagon, you can disable highlighting (Options / Code Inspection / Settings) and switch to Visual Studio native intellisense (Options / Environment / IntelliSense / General). This will help a bit, but still you cannot trust find usages results, refactorings and many other features.
There was also reported weird problem with Visual Studio 2008 and ReSharper installed on x64 computers - opening Visual Studio's Find dialog crashes. We are currently trying to reproduce this problem. If you experience this problem, please tell us!
Some people tend to ask for quick-and-dirty hack for ReSharper 3 so that it just parses the code and don't do anything intelligent with C# 3.0 code. It is not possible. Details are not important here and are pure technical.
Next version
ReSharper 4 is in very active development. Its main purpose is to support C# 3.0 in all of its beauty. This means not only parsing and code intelligence, but also new analysis, refactorings, context actions and quick fixes. We are concentrated on making your development experience with C# 3.0 as smooth and pleasant as possible.
Currently, we have support for implicity typed variables and arrays, extension methods, object and collection initializers and automatic properties. As soon as we complete support for lambdas, queries and anonymous types, we will open Early Access Program. We plan to achieve this goal in January, 2008.
From this point you will be able to download EAP or even nightly builds and try full power of ReSharper 4 with your new C# 3.0 code.
In regards of upgrade policy, we are currently in the process of deciding upgrade cost, who qualifies for free upgrade, or if we want to do something special about this release. I will post about it as soon as I can.
As for release plans, we are aiming at 2008'Q1, hopefully sometime soon after Visual Studio 2008 launch event in February. ReSharper 4 will be available to general public via Early Access Program at least for 2 months before release.
If you have any questions, do not hesitate to ask in comments.
Released version
ReSharper 3 can be installed with Visual Studio 2008 and works fine, unless you are using C# 3.0 new features, like lambdas, LINQ, extension methods and such. This constructs are not parsed by ReSharper 3, which was developed to support C# 2.0 only. It is not only highlighting which doesn't support C# 3.0, it is all the core and code intelligence. For example, rename refactoring will not find usages of extension methods and will not update them.
There also could be some glitches, even if you don't use new C# 3.0 constructs. This is due to the fact that C# 3.0 compiler is always used in Visual Studio 2008 C# projects, regardless of target framework. It it is not widely discussed, but changes in language are wider than just several new features. There are differences in type inference in generics and candidates lookup for binding, to name few. If you happen to hit this special cases, ReSharper could behave incorrectly.
If you are really-really going to immediately jump C# 3.0 wagon, you can disable highlighting (Options / Code Inspection / Settings) and switch to Visual Studio native intellisense (Options / Environment / IntelliSense / General). This will help a bit, but still you cannot trust find usages results, refactorings and many other features.
There was also reported weird problem with Visual Studio 2008 and ReSharper installed on x64 computers - opening Visual Studio's Find dialog crashes. We are currently trying to reproduce this problem. If you experience this problem, please tell us!
Some people tend to ask for quick-and-dirty hack for ReSharper 3 so that it just parses the code and don't do anything intelligent with C# 3.0 code. It is not possible. Details are not important here and are pure technical.
Next version
ReSharper 4 is in very active development. Its main purpose is to support C# 3.0 in all of its beauty. This means not only parsing and code intelligence, but also new analysis, refactorings, context actions and quick fixes. We are concentrated on making your development experience with C# 3.0 as smooth and pleasant as possible.
Currently, we have support for implicity typed variables and arrays, extension methods, object and collection initializers and automatic properties. As soon as we complete support for lambdas, queries and anonymous types, we will open Early Access Program. We plan to achieve this goal in January, 2008.
From this point you will be able to download EAP or even nightly builds and try full power of ReSharper 4 with your new C# 3.0 code.
In regards of upgrade policy, we are currently in the process of deciding upgrade cost, who qualifies for free upgrade, or if we want to do something special about this release. I will post about it as soon as I can.
As for release plans, we are aiming at 2008'Q1, hopefully sometime soon after Visual Studio 2008 launch event in February. ReSharper 4 will be available to general public via Early Access Program at least for 2 months before release.
If you have any questions, do not hesitate to ask in comments.
16 October 2007
C# 3.0 Automatic Properties - Incomplete Feature?
Well, C# 3.0 is nice language. However, digging into details of every new language feature while developing ReSharper support make me wonder about little things that look like incompleteness. Today I'm going to wonder about automatic properties.
This code is correct in C# 3.0, there are no missing "abstract" or get/set bodies. It simply means that compiler will create field and accessors code for you:
What is cool about automatic properties? Obviously, ReSharper users don't benefit much from shorter code - who types properties by hand these days? However there is one very important thing:
If you want to know how this property gets its value, you no longer need to search for both field and property usages. You don't need to synchronize field and property types, once you decide to change it. Also, access to the class attribute (in OOP sense) is fully controlled right at the place of the declaration. You can limit it as you wish:
This way you declare that "Name" can be modified only within the class itself, but can be read from outside.
So, what is missing from this language feature?
Initializer.
I may wish to initilize property to some non-default value. Like this:
Read-only automatic property
In the example above, I don't actually need setter.
Obviously, you don't need read-only automatic property without initializer. Also note, that such property can never change its value, even in constructor, unlike readonly fields.
Attributes on generated fields
If you use simple event form and compiler generates field for storing delegate, you can apply attribute to the generated field by using attribute target:
I wish I could do the same with automatic properties:
Conclusion
Few simple improvements over existing implementation could make automatic properties much more useful in everyday professional .NET development. Unfortunately, language designers decided:
I'd prefer the advanced version, if I had a chance to choose.
public string Name { get; set; }
This code is correct in C# 3.0, there are no missing "abstract" or get/set bodies. It simply means that compiler will create field and accessors code for you:
private string __someGeneratedFieldName;
public string Name
{get { return __someGeneratedFieldName; }
set { __someGeneratedFieldName = value; }
}
What is cool about automatic properties? Obviously, ReSharper users don't benefit much from shorter code - who types properties by hand these days? However there is one very important thing:
Less complexity to manage.
If you want to know how this property gets its value, you no longer need to search for both field and property usages. You don't need to synchronize field and property types, once you decide to change it. Also, access to the class attribute (in OOP sense) is fully controlled right at the place of the declaration. You can limit it as you wish:
public string Name { get; private set; }
This way you declare that "Name" can be modified only within the class itself, but can be read from outside.
So, what is missing from this language feature?
Initializer.
I may wish to initilize property to some non-default value. Like this:
public List<Person> Persons { get; private set; } = new List<Person>();
Read-only automatic property
In the example above, I don't actually need setter.
public List<Person> Persons { get; } = new List<Person>();
Obviously, you don't need read-only automatic property without initializer. Also note, that such property can never change its value, even in constructor, unlike readonly fields.
Attributes on generated fields
If you use simple event form and compiler generates field for storing delegate, you can apply attribute to the generated field by using attribute target:
[field: NonSerialized]public event EventHandler Closed;
I wish I could do the same with automatic properties:
[field: NonSerialized]public List<Person> Persons { get; } = new List<Person>();
Conclusion
Few simple improvements over existing implementation could make automatic properties much more useful in everyday professional .NET development. Unfortunately, language designers decided:
they would work in the "common case" which among other things means no attributes on the generated field. The idea behind that is keeping them simple and not slowly mutating them into full properties.
I'd prefer the advanced version, if I had a chance to choose.
07 September 2007
ReSharper 3.0.3 EAP and Solution-wide Error Analysis
The ReSharper team is actively working on next version with C# 3.0 support, but we are still fixing things for ReSharper 3.0 and even add new features!
Among with various bug-fixes, ReSharper 3.0.3 features "Global Error Analysis" feature that finds compilation errors in your solution on-the-fly. It was available in early ReSharper 3.0 EAP builds, but then we decided that it is not mature enough to put it into release. Now, we've improved it and are going to include it in ReSharper 3.0.3 update.
You can get ReSharper 3.0.3 EAP build at download page. Take a look at post about Early Access Program, if you want to learn more about participating.
To enable analysis of all errors in solution, double-click a red crossing lines symbol at the very right of the status bar and check the "Analyze errors in whole solution" checkbox. Note, that it is per-solution setting. It may take quite a while to analyze your solution for the first time (you can continue your work), but once the solution has been analyzed only those files that may be affected by the changes made are reanalyzed. Tool window with all errors in your solution can be opened using ReSharper | Windows | Errors in Solution menu command. Also, next/previous error command walks through all solution errors, if solution-wide error analysis is enabled.
We would like to hear from you about this feature! Do you like it or not? Does it work fine for you? Do you have any problems? You can leave comments to this post, or drop a message in our EAP newsgroup. Thanks in advance!
Among with various bug-fixes, ReSharper 3.0.3 features "Global Error Analysis" feature that finds compilation errors in your solution on-the-fly. It was available in early ReSharper 3.0 EAP builds, but then we decided that it is not mature enough to put it into release. Now, we've improved it and are going to include it in ReSharper 3.0.3 update.
You can get ReSharper 3.0.3 EAP build at download page. Take a look at post about Early Access Program, if you want to learn more about participating.
To enable analysis of all errors in solution, double-click a red crossing lines symbol at the very right of the status bar and check the "Analyze errors in whole solution" checkbox. Note, that it is per-solution setting. It may take quite a while to analyze your solution for the first time (you can continue your work), but once the solution has been analyzed only those files that may be affected by the changes made are reanalyzed. Tool window with all errors in your solution can be opened using ReSharper | Windows | Errors in Solution menu command. Also, next/previous error command walks through all solution errors, if solution-wide error analysis is enabled.
We would like to hear from you about this feature! Do you like it or not? Does it work fine for you? Do you have any problems? You can leave comments to this post, or drop a message in our EAP newsgroup. Thanks in advance!
06 September 2007
C# 3.0 Collection Initializers - Incomplete Feature?
I was really confused when I learned that "collection initializer" is so limited. I thought it was so natural to support extension methods for "Add" method, but it doesn't.
In short, collection initializer is the following syntax:
Each item in the braces is simply transformed to the call of Add method with appropriate signature.
It's a bit more complex in reality, but it doesn't matter here.
So, when I first saw description of the feature I thought: How cool! I can specify extension method "Add" for "StringBuilder" and get the following:
But, restrictions are too strong - type being constructed should implement IEnumerable and have instance method "Add". IEnumerable is not of a big deal, but inability to use extension methods for Add is deal breaker.
How about this?
No way. You can't use collection initializer for XmlDocument, because it doesn't have Add methods. It is IEnumerable, though.
May be this?
No way. PermissionSet is IEnumerable too, but does have AddPermission instead of Add method.
If it only were searching for candidates as follows:
This change, or something similar, would turn the otherwise very limited collection initializers into really powerfull object initialization feature.
In short, collection initializer is the following syntax:
var list = new List<int> { 1, 2, 3 };
var dic = new Dictionary<int,string> { { 1, "a" }, { 2, "b" }, { 3, "c" } };
Each item in the braces is simply transformed to the call of Add method with appropriate signature.
var list = new List<int>();
list.Add(1);
list.Add(2);
list.Add(3);
var dic = new Dictionary<int,string>();
dic.Add(1,"a");
dic.Add(2,"b");
dic.Add(3,"c");
It's a bit more complex in reality, but it doesn't matter here.
So, when I first saw description of the feature I thought: How cool! I can specify extension method "Add" for "StringBuilder" and get the following:
var sb = new StringBuilder { "Text = ", Text, ";", "Value = ", Value };
But, restrictions are too strong - type being constructed should implement IEnumerable and have instance method "Add". IEnumerable is not of a big deal, but inability to use extension methods for Add is deal breaker.
How about this?
XmlDocument doc = new XmlDocument
{
new Node("person") { Attributes = { { "name", "John" }, { "age", "42" } },
Nodes =
{
new Node("phones") { Nodes =
{
new Node("number") { Value = "123 45 678" },
new Node("number") { Value = "777 77 777" },
new Node("number") { Value = "987 65 432" }
}
}
}
No way. You can't use collection initializer for XmlDocument, because it doesn't have Add methods. It is IEnumerable, though.
May be this?
var set = new PermissionSet( new ZoneIdentityPermission(...), new PrincipalPermission(...) };
No way. PermissionSet is IEnumerable too, but does have AddPermission instead of Add method.
If it only were searching for candidates as follows:
- If type implements "IEnumerable", look for instance Add method with appropriate parameters,
- If not found, if type implements "IEnumerable", look for extension method Add with appropriate parameters,
- If not found, look for extension method AddToSequence with appropriate parameters.
This change, or something similar, would turn the otherwise very limited collection initializers into really powerfull object initialization feature.
04 September 2007
Visualize Right Margin in Visual Studio
ReSharper has formatting option to keep your source code lines below certain limit.
In Options, go to Languages / C# / Formatting Style / Line Breaks and Wrapping, find "Wrap long lines" below "Line Wrapping" group and enable it, then set "Right margin (columns)" to the desired value. That's pretty cool, but how can one see which lines will be wrapped?
Meet Visual Studio secret feature: Guides!
As described in this blog post, you can play a bit with registry and make Visual Studio display nice dotted vertical lines at specific column:
Now you will be able to see when your lines are too long, and probably make manual formatting before ReSharper will split lines at next reformat.
In Options, go to Languages / C# / Formatting Style / Line Breaks and Wrapping, find "Wrap long lines" below "Line Wrapping" group and enable it, then set "Right margin (columns)" to the desired value. That's pretty cool, but how can one see which lines will be wrapped?
Meet Visual Studio secret feature: Guides!
As described in this blog post, you can play a bit with registry and make Visual Studio display nice dotted vertical lines at specific column:
- Open "HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\Text Editor" key
- Create new string value "Guides"
- Set its value to something like "RGB(192,192,192) 119" (columns in registry are zero-based)
- Restart Visual Studio
Now you will be able to see when your lines are too long, and probably make manual formatting before ReSharper will split lines at next reformat.
Subscribe to:
Posts (Atom)
