Visual Studio becomes rather slow when building solutions with lots of project dependencies. To improve performance many users reference output assemblies of projects rather than the projects themselves. So, suppose you have a solution located at C:\Solution with two C# projects, say, A and B with outputs located at C:\Solution\A\Output\Release\A.dll and C:\Solution\B\Output\Release\B.exe. If you wish to reference A from B you can do this in two ways. You can add reference to project A in the Add Reference... menu (reference project), or you can add reference to C:\Solution\A\Output\Release\A.dll in the same menu but on the other tab (reference assembly). If you develop in VS without ReSharper (which is, naturally, utter bore;) it does not matter in which way you reference. But if you do use ReSharper you would expect it to be smart enough, for example, to rename usages of interface I from project A found in project B, independently of the way you reference A from B. Unfortunately, in version 1.0 users had to reference A from B as a project, otherwise ReSharper would not refactor (and do other things) "inter-project". In version 1.5 ReSharper will understand (actually, it does from build 154) referencing assembly output as if the project itself is referenced (and perform inter-project rename etc), though we do not recommend using this practice.
What about the case where you have a common bin directory?
Given your example below, what if B referenced A by refering to A.dll in C:\project\common\bin? (imagine A's project has a post-build step that copies the DLL to this directory). Can Resharper still figure out that this DLL reference is the same as the project that's loaded in the solution?
Visual Studio becomes rather slow when building solutions with lots of project dependencies. To improve performance many users reference output assemblies of projects rather than the projects themselves. So, suppose you have a solution located at C:\Solution with two C# projects, say, A and B with outputs located at C:\Solution\A\Output\Release\A.dll and C:\Solution\B\Output\Release\B.exe. If you wish to reference A from B you can do this in two ways. You can add reference to project A in the Add Reference... menu (reference project), or you can add reference to C:\Solution\A\Output\Release\A.dll in the same menu but on the other tab (reference assembly). If you develop in VS without ReSharper (which is, naturally, utter bore;) it does not matter in which way you reference. But if you do use ReSharper you would expect it to be smart enough, for example, to rename usages of interface I from project A found in project B, independently of the way you reference A from B. Unfortunately, in version 1.0 users had to reference A from B as a project, otherwise ReSharper would not refactor (and do other things) "inter-project". In version 1.5 ReSharper will understand (actually, it does from build 154) referencing assembly output as if the project itself is referenced (and perform inter-project rename etc), though we do not recommend using this practice.
yes, it can. Basically, ReSharper compares the short name of the output assembly of the project A (A.dll in the case) with the short name of the given referenced assembly (smth like C:\Solution\Bin\A.dll) to check their identity. Unfortunately, in presence of post-build steps there is no other reliable way for doing this.
What about the case where you have a common bin directory?
Given your example below, what if B referenced A by refering to A.dll in C:\project\common\bin? (imagine A's project has a post-build step that copies the DLL to this directory). Can Resharper still figure out that this DLL reference is the same as the project that's loaded in the solution?
>> Visual Studio becomes rather slow when building solutions with lots >> of >> project dependencies. To improve performance many users reference >> output >> assemblies of projects rather than the projects themselves. >> So, suppose you have a solution located at C:\Solution with two C# >> projects, say, A and B with outputs located at >> C:\Solution\A\Output\Release\A.dll and >> C:\Solution\B\Output\Release\B.exe. >> If you wish to reference A from B you can do this in two ways. You >> can add >> reference to project A in the Add Reference... menu (reference >> project), >> or you can add reference to C:\Solution\A\Output\Release\A.dll in the >> same >> menu but on the other tab (reference assembly). >> If you develop in VS without ReSharper (which is, naturally, utter >> bore;) >> it does not matter in which way you reference. But if you do use >> ReSharper >> you would expect it to be smart enough, for example, to rename usages >> of >> interface I from project A found in project B, independently of the >> way >> you reference A from B. >> Unfortunately, in version 1.0 users had to reference A from B as a >> project, otherwise ReSharper would not refactor (and do other things) >> "inter-project". In version 1.5 ReSharper will understand (actually, >> it >> does from build 154) referencing assembly output as if the project >> itself >> is referenced (and perform inter-project rename etc), though we do >> not >> recommend using this practice. >> -- >> Andrey Simanovsky >> Software Developer >> JetBrains, Inc >> http://www.jetbrains.com >> "Develop with pleasure!" >> "Kelly Summerlin" <no_mail@jetbrains.com> wrote in message >> news:8751887.1107020523192.JavaMail.itn@is.intellij.net... >> >>> This was mentioned as a change in build 154. What exactly does this >>> mean? What does this affect and how does it affect me? >>> >>> TKS >>>
Visual Studio becomes rather slow when building solutions with lots of
project dependencies. To improve performance many users reference output
assemblies of projects rather than the projects themselves.
So, suppose you have a solution located at C:\Solution with two C# projects,
say, A and B with outputs located at C:\Solution\A\Output\Release\A.dll and
C:\Solution\B\Output\Release\B.exe. If you wish to reference A from B you
can do this in two ways. You can add reference to project A in the Add
Reference... menu (reference project), or you can add reference to
C:\Solution\A\Output\Release\A.dll in the same menu but on the other tab
(reference assembly).
If you develop in VS without ReSharper (which is, naturally, utter bore;) it
does not matter in which way you reference. But if you do use ReSharper you
would expect it to be smart enough, for example, to rename usages of
interface I from project A found in project B, independently of the way you
reference A from B.
Unfortunately, in version 1.0 users had to reference A from B as a project,
otherwise ReSharper would not refactor (and do other things)
"inter-project". In version 1.5 ReSharper will understand (actually, it does
from build 154) referencing assembly output as if the project itself is
referenced (and perform inter-project rename etc), though we do not
recommend using this practice.
--
Andrey Simanovsky
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Kelly Summerlin" <no_mail@jetbrains.com> wrote in message
news:8751887.1107020523192.JavaMail.itn@is.intellij.net...
>
>
What about the case where you have a common bin directory?
Given your example below, what if B referenced A by refering to A.dll in
C:\project\common\bin? (imagine A's project has a post-build step that
copies the DLL to this directory). Can Resharper still figure out that this
DLL reference is the same as the project that's loaded in the solution?
"Andrey Simanovsky (JetBrains)" <ands@jetbrains.com> wrote in message
news:ctkvj1$m3l$1@is.intellij.net...
>
>
>
>
>
>> This was mentioned as a change in build 154. What exactly does this mean?
>> What does this affect and how does it affect me?
>>
>>
>> TKS
>
Hello Paul,
yes, it can. Basically, ReSharper compares the short name of the output assembly
of the project A (A.dll in
the case) with the short name of the given referenced assembly (smth like
C:\Solution\Bin\A.dll) to check their identity.
Unfortunately, in presence of post-build steps there is no other reliable
way for doing this.
Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> Visual Studio becomes rather slow when building solutions with lots
>> of
>> project dependencies. To improve performance many users reference
>> output
>> assemblies of projects rather than the projects themselves.
>> So, suppose you have a solution located at C:\Solution with two C#
>> projects, say, A and B with outputs located at
>> C:\Solution\A\Output\Release\A.dll and
>> C:\Solution\B\Output\Release\B.exe.
>> If you wish to reference A from B you can do this in two ways. You
>> can add
>> reference to project A in the Add Reference... menu (reference
>> project),
>> or you can add reference to C:\Solution\A\Output\Release\A.dll in the
>> same
>> menu but on the other tab (reference assembly).
>> If you develop in VS without ReSharper (which is, naturally, utter
>> bore;)
>> it does not matter in which way you reference. But if you do use
>> ReSharper
>> you would expect it to be smart enough, for example, to rename usages
>> of
>> interface I from project A found in project B, independently of the
>> way
>> you reference A from B.
>> Unfortunately, in version 1.0 users had to reference A from B as a
>> project, otherwise ReSharper would not refactor (and do other things)
>> "inter-project". In version 1.5 ReSharper will understand (actually,
>> it
>> does from build 154) referencing assembly output as if the project
>> itself
>> is referenced (and perform inter-project rename etc), though we do
>> not
>> recommend using this practice.
>> --
>> Andrey Simanovsky
>> Software Developer
>> JetBrains, Inc
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>> "Kelly Summerlin" <no_mail@jetbrains.com> wrote in message
>> news:8751887.1107020523192.JavaMail.itn@is.intellij.net...
>>
>>> This was mentioned as a change in build 154. What exactly does this
>>> mean? What does this affect and how does it affect me?
>>>
>>> TKS
>>>