Namespace alias

When I work with VSTO I usually create the following namesapace aliases (I
don't know the real name of this):

using Office = Microsoft.Office.Core;
using Outlook = Microsoft.Office.Interop.Outlook;
...
{
applicationObject = application as Outlook.Application;
addInInstance = addInInst as Office.COMAddIn;
}


Whenever I later want to reformat the class ReSharper will get rid of this
and change it to just:

using Microsoft.Office.Core;
using Microsoft.Office.Interop.Outlook;
...
{
applicationObject = application as Application;
addInInstance = addInInst as COMAddIn;
}

Questions:
1. Is there a way to prevent this? (I still want to use the Reformat
feature.)
2. Are there plans to allow keeping the namespace aliases?

Thanks,
David.


10 comments
Comment actions Permalink

Though you can tell ReSharper to not to remove namespace aliases on
reformat, it won't use it because it would prefer import that namespace,
rather than left reference qualified

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"David Pokluda" <info@online.pokluda.cz> wrote in message
news:foq0ql$aav$1@is.intellij.net...

When I work with VSTO I usually create the following namesapace aliases (I
don't know the real name of this):

>

using Office = Microsoft.Office.Core;
using Outlook = Microsoft.Office.Interop.Outlook;
...
{
applicationObject = application as Outlook.Application;
addInInstance = addInInst as Office.COMAddIn;
}

>
>

Whenever I later want to reformat the class ReSharper will get rid of this
and change it to just:

>

using Microsoft.Office.Core;
using Microsoft.Office.Interop.Outlook;
...
{
applicationObject = application as Application;
addInInstance = addInInst as COMAddIn;
}

>

Questions:
1. Is there a way to prevent this? (I still want to use the Reformat
feature.)
2. Are there plans to allow keeping the namespace aliases?

>

Thanks,
David.



0
Comment actions Permalink

I don't think I understand. You say I can tell ReSharper not to remove those
and at the same time you say it will not work? Isn't that a bug then?

How do I tell ReSharper to not remove namespace aliases?

Thanks,
David.

"Eugene Pasynkov (JetBrains)" <Eugene.Pasynkov@jetbrains.com> wrote in
message news:fortr8$vi8$1@is.intellij.net...

Though you can tell ReSharper to not to remove namespace aliases on
reformat, it won't use it because it would prefer import that namespace,
rather than left reference qualified

>

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"David Pokluda" <info@online.pokluda.cz> wrote in message
news:foq0ql$aav$1@is.intellij.net...

>> When I work with VSTO I usually create the following namesapace aliases
>> (I don't know the real name of this):
>>
>> using Office = Microsoft.Office.Core;
>> using Outlook = Microsoft.Office.Interop.Outlook;
>> ...
>> {
>> applicationObject = application as Outlook.Application;
>> addInInstance = addInInst as Office.COMAddIn;
>> }
>>
>>
>> Whenever I later want to reformat the class ReSharper will get rid of
>> this and change it to just:
>>
>> using Microsoft.Office.Core;
>> using Microsoft.Office.Interop.Outlook;
>> ...
>> {
>> applicationObject = application as Application;
>> addInInstance = addInInst as COMAddIn;
>> }
>>
>> Questions:
>> 1. Is there a way to prevent this? (I still want to use the Reformat
>> feature.)
>> 2. Are there plans to allow keeping the namespace aliases?
>>
>> Thanks,
>> David.
>>
>


0
Comment actions Permalink

You've understood me correctly. And this is not the bug. Let me explain:

Step 1: You have the following code:
using Outlook = Microsoft.Office.Interop.Outlook;
...
applicationObject = application as Outlook.Application;

Step2: On shortening references, ReSharper convert the code into the
following:
using Outlook = Microsoft.Office.Interop.Outlook;
...
applicationObject = application as Application;
keeping in mind that "Application" is actually
"Microsoft.Office.Interop.Outlook.Application"

Step3: ReSharper has to make sure that "Application" is resolved to reminded
class. It has 2 ways: qualify reference (and thus use your alias), either
say "using Microsoft.Office.Interop.Outlook" without other modifications in
user code. The second approach has more priority in ReSharper's core
algorithms, so additional "using" directive is inserted.


Way to partially solve the problem - ask ReSharper to not to shorten
references during code reformat


--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"David Pokluda" <info@online.pokluda.cz> wrote in message
news:fovbh4$qmu$1@is.intellij.net...
>I don't think I understand. You say I can tell ReSharper not to remove
>those and at the same time you say it will not work? Isn't that a bug then?
>

How do I tell ReSharper to not remove namespace aliases?

>

Thanks,
David.

>

"Eugene Pasynkov (JetBrains)" <Eugene.Pasynkov@jetbrains.com> wrote in
message news:fortr8$vi8$1@is.intellij.net...

>> Though you can tell ReSharper to not to remove namespace aliases on
>> reformat, it won't use it because it would prefer import that namespace,
>> rather than left reference qualified
>>
>> --
>> Eugene Pasynkov
>> Developer
>> JetBrains, Inc
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>> "David Pokluda" <info@online.pokluda.cz> wrote in message
>> news:foq0ql$aav$1@is.intellij.net...
>>> When I work with VSTO I usually create the following namesapace aliases
>>> (I don't know the real name of this):
>>>
>>> using Office = Microsoft.Office.Core;
>>> using Outlook = Microsoft.Office.Interop.Outlook;
>>> ...
>>> {
>>> applicationObject = application as Outlook.Application;
>>> addInInstance = addInInst as Office.COMAddIn;
>>> }
>>>
>>>
>>> Whenever I later want to reformat the class ReSharper will get rid of
>>> this and change it to just:
>>>
>>> using Microsoft.Office.Core;
>>> using Microsoft.Office.Interop.Outlook;
>>> ...
>>> {
>>> applicationObject = application as Application;
>>> addInInstance = addInInst as COMAddIn;
>>> }
>>>
>>> Questions:
>>> 1. Is there a way to prevent this? (I still want to use the Reformat
>>> feature.)
>>> 2. Are there plans to allow keeping the namespace aliases?
>>>
>>> Thanks,
>>> David.
>>>
>>
>>




0
Comment actions Permalink

Can you guys reconsider this ;-)

I'm having the same problem with namespace aliases being removed -- it happens during refactorings as well, which is very painful.

0
Comment actions Permalink

Hello,

if you are using 'Code Cleaup' function, you can define your own rules.
Go to R# Options, select Code Cleanup (on the bottom),  click Add and uncheck "Optimize 'using' directives"

Hope this helps.

0
Comment actions Permalink

It isn't code cleanup that is the problem, I am having a lot of problems with the "extract method" refactoring. If I have:

using ABC = Foo.Bar.Baz;

ABC.MyClass x = new ABC.MyClass();

// ... lots of calculations here

And I do an extract method, I will end up with:

uisng Foo.Bar.Baz;

using ABC = Foo.Bar.Baz;

ABC.MyClass x = RefactoredMethod();

MyClass RefactoredMethod()

{

    MyClass x = new MyClass();

    // ... lots of calculations here

    return x;

}

This is a pain because I have to go back and fix things, making it easier to extract the method manually :-(

0
Comment actions Permalink

I'd like to second Laurion Burchall - could you please reconsider this? We would like to use the shorten references feature, but would like explicit namespace aliases preserved. An explicit namespace alias means that the developer intended to specify a namespace either to avoid collisions or for clarity, and this should not be removed.

0
Comment actions Permalink

LaurionB wrote:

<...>

And I do an extract method, I will end up with:

uisng Foo.Bar.Baz;

using ABC = Foo.Bar.Baz;

<..>


You are not using Resharper Options->Namespace Imports->"Use fully qualified names" ?
This option does not insert the "using" statements (however it will still not use your aliases but it might help you out a little bit).

0
Comment actions Permalink

I've been using Resharper for many years and I beg you to consider adding this feature too, because it messes up my code all the time.

For example, I have the following code:


using D3D = SharpDX.Direct3D;
using D3D11 = SharpDX.Direct3D11;
using D2D = SharpDX.Direct2D1;
using DWrite = SharpDX.DirectWrite;


...

private D3D11.Device _d3DDevice;
private D2D.Factory _d2DFactory;
private DWrite.Factory _dWriteFactory;




After some refactorings (like fixing namespaces), depending on the settings, R# converts my code either to:


private Device _d3DDevice;
private SharpDX.Direct2D1.Factory _d2DFactory;
private SharpDX.DirectWrite.Factory _dWriteFactory;


or

using SharpDX.Direct3D;
using SharpDX.Direct3D11;
using SharpDX.Direct2D1;
using Debug = System.Diagnostics.Debug;
using Factory = SharpDX.Direct2D1.Factory;
using FactoryType = SharpDX.Direct2D1.FactoryType;
using FeatureLevel = SharpDX.Direct3D.FeatureLevel;

private Device _d3DDevice;
private Factory _d2DFactory;
private SharpDX.DirectWrite.Factory _dWriteFactory;
.
.





I just adjusted all my namespaces in my solutions, and fixing the namespace aliases again is a real pain.
.
.





I would love a feature like "always use the <D2D> alias for the namespace <SharpDX.Direct2D1>"
.
.




Thanks,
Peter
0
Comment actions Permalink

+1 for an option to preserve explicit namespace aliases.

It's not just for code cleanup; at the moment, almost any R# action removes the aliases and changes the declarations in the current file. I then either have to undo the R# action, or replace the using directive with the alias and fix the dozens of errors this introduces, whilst trying to avoid accidentally invoking the "resolve type" action which would undo all of my changes.

If possible, I'd also like an option to specify that a particular namespace should never be imported. One of the third-party libraries I work with has a single TLA namespace, and for the sake of clarity I'd prefer to use fully-qualified names for the types in that namespace. Adding a "using BIG = BIG;" might work if I could tell R# to preserve the alias, but it seems a little redundant.

0

Please sign in to leave a comment.