new deep zoom related enhancements - click below

Click Here to Watch What’s New

9 our of 10 studies prove: Resharper make your your hair grow back, your dog come home (yes even if he died), your wife will love you again and your kids will listen to you.

OK perhaps it is not a country music song played backwards.

BUT your nuts to even think about wasting all that time not using it. For someone who knows it is people not tools that always win, this is my only exception in 20 years that I will stand behind.

Why stare at a keyboard for hours wondering how to navigate a nasty tangled refactoring you know you must do when you can do the right thing AND make the 5:30 train.

Me? I hit the shift-ctrl-space repeatedly and am shocked when nothing happens. Then I install it and life is good again.

ReSharper 4.5 Released

April 8, 2009

In This Issue

Introduction
Performance and Memory Usage Improvements
Solution-Wide Code Inspections

VB9 Support
Extended Naming Style Configuration
Other Enhancements

Introduction

ReSharper 4.5 is finally out, so your next productivity upgrade is just a mouse click away!

As announced, the new version features major improvements in performance and memory usage. After all, what is a productivity tool for if not for being agile, robust and responsive?

In addition to focusing on performance enhancements, we also added a number of intelligence features and improvements.

We’ve prepared a short Flash movie to introduce the new features in ReSharper 4.5. Get the hang of things in just a few minutes!

For users of older versions we have a ReSharper 3.0 vs. ReSharper 4.5 Comparison matrix.

However, if you believe a thousand words say more than a picture does, or even a movie, go ahead and read the descriptions below :)

Alex Morozov
NET product marketing manager 
JetBrains

Performance and Memory Usage Improvements

We have managed to make ReSharper load and work faster and more smoothly in general, particularly on big (and we mean BIG) solutions:

• Wall-time measurements of solution loading show 20 to 40 percent acceleration until the solution is ready for code editing.
• Web site loading time has also been reduced by a third.
• For instance, a certain mixed-language solution consisting of about 15 thousand classes now takes only 70 seconds to load, and this includes making every ReSharper feature available.

The list of significantly accelerated operations includes:

• renaming symbols
• finding commonly used symbols
• creating symbols from usage
• analyzing large XAML files.

We’ve also cut down the volume of memory resources required to analyze jumbo autogenerated code files, which should especially benefit those who work with ASP.NET and LINQ to SQL.

Solution-Wide Code Inspections

To enable you to detect unused non-private members on the fly, we have enlisted the help of our ever-improving solution-wide analysis. We have introduced a set of specialized code inspections that only work when you let ReSharper analyze your whole solution. They help you discover:

• Unused non-private declarations
• Unused return values of non-private methods
• Unaccessed non-private fields
• Unused parameters in non-private members
• Abstract or virtual events that are never invoked
• Unassigned fields
• Members and types that can be made internal instead of public

Look for these inspections in your code and on the Marker Bar, highlighted as warnings or suggestions. In addition, new code annotations are available that you can use to mark certain unused non-private types and members to prevent ReSharper from fussing about them.

VB9 Support – We can forgive this transgression (Damon)

Visual Basic .NET developers can now benefit from VB9 language support that includes implicitly typed local variables, object initializers, anonymous types, extension methods, lambda expressions, partial methods, and embedded XML. VB9 support is all around you, courtesy of new context actions, code completion, refactorings, and Parameter Info, among other supporting features.

Extended Naming Style Configuration

Now you can define custom naming style settings for different languages and symbols including:

• types
• namespaces
• interfaces
• parameters
• method properties and events
• static and instance fields, etc.

For every kind of symbol, you can configure one of five casing options, prefixes and suffixes, variations for different access rights, abbreviations to preserve, or enable naming inspections. As a result, you can precisely align the way ReSharper completes and generates code with your specific coding guidelines.

Other Enhancements

• Go to Implementation – This new navigation feature lets you jump from usage of a base type or member to any of its end implementations, bypassing intermediate steps in the inheritance chain.
• New and Improved Refactorings – ReSharper 4.5 has added Inline Field to its family of Inline refactorings. Rename refactoring now provides name completion, and some of the other refactorings were thoroughly refactored themselves, to make them perform faster.
• Native MSTest Support – Initially available through VstsUnit Plugin and then Gallio, MSTest support has finally made its way to being provided natively in ReSharper, on par with nUnit.
• Wider Cross-Language Capabilities – Quick-fixes and context actions work better in many cross-language scenarios: for example, you can extend a control written in VB.NET+XAML by choosing "create from usage" right from a C# usage. Add increased coverage for XAML and ASP.NET, and you get a substantial package of improvements.
• Smoother Language and Framework Support – Following the tradition of ReSharper 4.1, we have improved compatibility with F#, Compact Framework, Silverlight 2, and other languages and tools.

Grab your all-new productivity – download ReSharper 4.5 now at http://www.jetbrains.com/resharper/download.

ReSharper 4.5 is provided as a free upgrade from ReSharper 4.0. If you own an older version, please contact us to check your upgrade availability at sales@jetbrains.com.

JetBrains Team

• Sergey
  Anchipolevsky

• Igor
  Alshannikov

• Alexander
  Anisimov

• Dmitry
  Avdeev

• Sergey
  Baranov

• Yury
  Belyaev

• Natalia
  Belyaeva

• Elena
  Bukreeva

• Bulenkov
  Konstantin

• Jana
  Charif

• Nikolay
  Chashnikov

• Alexander
  Chernikov

• Roman
  Chernyatchik

• Sergey
  Coox

• Sergey
  Dmitriev

• Ilia
  Dumov

• Kirill
  Falk

• Michael
  Gerasimov

• Sergey
  Golovachev

• Alexey
  Gopachenko

• Peter
  Gromov

• Michaela
  Hroncová

• Dmitry
  Jemerov

• Maria
  Khalusova

• Valentin
  Kipiatkov

• Cyril
  Konopko

• Anna
  Kozlova

• Mikhail
  Kropotov

• Eugene
  Kudelevsky

• Alexey
  Kudravtsev

• Olga
  Lobacheva

• Vyacheslav
  Lukianov

• Anton
  Makeev

• Egor
  Malyshev

• Maria
  Marakulina

• Kirill
  Maximov

• Sasha
  Maximova

• Irina
  Megorskaya

• Lucie
  Morawiecova

• Alexander
  Morozov

• Maxim
  Mossienko

• Ekaterina
  Musienko

• Ann
  Oreshnikova

• Eugene
  Pasynkov

• Vaclav
  Pech

• Alexey
  Pegov

• Eugene
  Petrenko

• Irina
  Petrovskaya

• Mikhail
  Pilin

• Julia
  Repina

• Elizaveta
  Revyakina

• Ilya
  Ryzhenkov

• Andrew
  Serebryansky

• Ilya
  Sergey

• Maxim
  Shafirov

• Tatiana
  Slavina

• Olesya
  Smirnova

• Konstantin
  Solomatov

• Oleg
  Stepanov

• Pavel
  Sher

• Ekaterina
  Shliakhovetskaja

• Oleg
  Shpynov

• Gregory
  Shrago

• Eugene
  Toporov

• George
  Udov

• Sergey
  Vasiliev

• Natalie
  Yaremych

• Yegor
  Yarko

• Timur
  Zambalayev

• Sergey
  Zhukov

• Eugene
  Zhuravlev

• Alexander
  Zverev

As long time advocates of domain-driven practice it should be no surprise that we prefer ‘Domain Specific Language’ approaches.

Of course now it seems obvious to everyone that these are the future. Sure there were many bumps in the road, but it is not even an interesting debate about ‘if’.

This article is so good from Martin Fowler we had to repost:

TIP: .NET Developer? Start learning the Oslo set of technologies, especially’ all things ‘M’. We pay tribute to ‘M’ in our demo Silverlight cube on Silverlight.net showcase.

DslMigration
dsl
4 February 2009
Reactions

One danger that DSL advocates need to guard against is the notion that first you design a DSL, then people use it. Like any other deice of software, a successful DSL will evolve. This means that scripts written in an earlier version of a DSL may fail when run with a later version.

Like many properties of DSL, good and bad, this is really very much the same as happens with a library. If you take a library from a someone and they upgrade the library, you may end up stuck. In essence DSLs don’t really do anything to change that. Your DSL definition is essentially a PublishedInterface and you have to deal with the consequences just the same.

This problem can be more prominent with external DSLs. Many changes to an internal DSL can be handled through refactoring tools (for those languages that have them). But refactoring tools won’t help with an external DSL. In practice this problem is less of an issue than it might be. An internal DSL with scripts that are outside the control of the DSL implementers won’t be picked up with refactoring. So the only difference between internal and external lies with DSL scripts within the same code base.

One technique for handling evolution of DSLs is to provide tools that automatically migrate a DSL from one version to another. These can be run either during an upgrade, or automatically should you try to run an old version script against a new version.

There are two broad ways to handle migration. The first is an incremental migration strategy. This is essentially the same notion that’s used by people doing evolutionary database design. For every change you do to your DSL definition, create a migration program that automatically migrates DSL scripts from the old version to the new version.

An important part of incremental migration is that you keep the changes as small as you can. Imagine you are upgrading from version 1 to 2, and have ten changes you want to make to your DSL definition. In this case, don’t create just one migration script to migrate from version 1 to 2, instead create at least 10 scripts. Change the DSL definition one feature at a time, and write a migration script for each change. You may find it useful to break it down even more and add a feature with more than one step (and thus more than one migration). They way I’ve described it may sound like more work than a single script, but the point is that migrations are much easier to write if they are small, and it’s easy to chain multiple migrations together. As a result you’ll be much faster writing ten scripts than one.

The other approach is model-based migration. This is a tactic you can use if you are using a Semantic Model (which is something I almost always recommend). With this approach you support multiple parsers for your language, one for each released version. (So you only do this for version 1 and 2, not for the intermediate steps.) Each parser populates the semantic model. When you use a semantic model, the parser’s behavior is pretty simple, so it’s not too much trouble to have several of them around. You then run the appropriate parser for the version of script you are working with. This handles multiple versions, but doesn’t migrate the scripts. To do the migration you write a generator from the semantic model that generates a DSL script representation. This way you can run the parser for a version 1 script, populate the semantic model, and then emit a version 2 script from the generator.

One problem with the model-based approach is that it’s easy to lose stuff that doesn’t matter to the semantics, but is something that the script writers want to keep. Comments are the obvious example. This is exacerbated if there’s too much smarts in the parser, but then the need to migrate this way may help encourage the parsers to stay dumb – which is Good Thing.

If the change to the DSL is big enough, you may not be able to transform a version 1 script into a version 2 semantic model. In which case you may need to keep a version 1 model (or intermediate model) around and give it the ability to emit a version 2 script.

I don’t have a strong preference between these two alternatives.

Migration scripts can be run by script programmers themselves when needed, or automatically by the DSL system. In order to run automatically it’s very useful to have the script record which version of the DSL it is so the parser can detect it easily and trigger the resulting migrations.

Microsoft “Oslo” Frequently Asked Questions

The new Architecture Explorer enables individuals to create a visual representation of existing code assets.

From MSDN (with added commentary….)

Modeling that Works with Code

For most businesses only about 20% of the code being written today is for new applications;

(DDN: Not true 100% however that is about right for budgets which is likely what they meant anyway).

the majority of work is being done on existing code bases. A typical issue encountered when working on existing code is not having good tools to help the architect or developer understand the system.

(DDN: Uh.. How about no regression tests? How about no mandate for reuse, framework API quality, etc. etc.? Sure lets not talk about the why, just the ways we can profit from it)

This can make it challenging to not only understand what needs to be done to make the required changes, but it makes it equally challenging to understand the broader impact of the changes. Often it isn’t until much later that an unexpected bug is discovered as a result of a change.

Our modeling tools have tight integration into the actual code of the application. This means that a developer or architect can use models to explore existing code assets.

Ugh.. Rational Round Trip UML nightmare but this should be part of your world at a minimum from code to view.

The new Architecture Explorer in Visual Studio Team System gives developers and architects the capability of creating a full architectural picture of existing code; understanding how they fit together; understanding how they “work.” This leads to better information about how to use, re-use, or even whether or not to discard existing code. The Architecture Explorer provides architects and developers a mechanism for visualizing code assets in a number of ways including graphs, stacked diagrams and dependency matrices.

DDN: OK now I am officially getting scared… I can see all the developers saying ‘look ma! I’m an architect!’

The introduction of the Architecture Layer Diagram means that a developer or architect can use models to enforce constraints on code as well. The Architecture Layer Diagram can be coupled to code making it an active diagram that can be used for validation.

For example, when an architect designs a system where the presentation layer should not talk to the data layer, you want to be able to enforce that model at check-in.

DDN: Oh my god was that last sentence serious? As if that would be a real interesting case?

VSTS 2010 can do that. These capabilities delivered in VSTS 2010 are part of the Microsoft’s overall modeling story.

Learn more about modeling by watching the Trends in Software Modeling webcast featuring Jeffrey Hammond (Forrester Research), Cameron Skinner (Microsoft, Visual Studio Team System), and Clemens Reijnen (Sogeti).

Related Posts