Updating references

How does R# handle updating references? (VS2003, .Net1.1, R# 254, XP)

I had a situation where I had one instance of VS with a class library project and another one with a console app using the DLL from the first one. Solutions were both open at the same time.

I went into the first one and changed an Enum name (thank you R#!) and then rebuilt. Went into the second one and replaces all occurrences of the old name with the new name.
Rebuilding the second project went fine, except R# complaining it "Cannot resolve symbol..."

The same for methods. Some refactoring in the first project (thank you again R#!), was not picked up by R# in the second solution, even though it builds just fine.

Any ideas?

8 comments
Comment actions Permalink

Hello Philip,

are you sure that even switching focus back and forth to the instance of
VS which doesn't seem to recognize changes doesn't help? I'm asking because
ReSharper does synchronization with external changes
(including those of referenced assemblies) when the user activates VS window.
Could you also please attach ReSharper log (ReSharper|Show Log) and tell
us how the referenced assembly (which is an image of the project you've modified)
is named? Thanks.


Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

How does R# handle updating references? (VS2003, .Net1.1, R# 254, XP)

I had a situation where I had one instance of VS with a class library
project and another one with a console app using the DLL from the
first one. Solutions were both open at the same time.

I went into the first one and changed an Enum name (thank you R#!) and
then rebuilt. Went into the second one and replaces all occurrences of
the old name with the new name.

Rebuilding the second project went fine, except R# complaining it
"Cannot resolve symbol..."

The same for methods. Some refactoring in the first project (thank you
again R#!), was not picked up by R# in the second solution, even
though it builds just fine.

Any ideas?



0
Comment actions Permalink

Hi Philip,

I don't believe there's any cross-instance communication between instances of your VS. Therefore, changes made to files by one instance will be detected by the other instance. However, say you have additional projects in your second instance, then any references to modified names (for example) won't be changed, as the first instance cannot see them.

I address this problem by loading all my projects in one solution, and just changing the default project depending upon what I'm working on.

I hope that helps you.

Drew.

0
Comment actions Permalink

Hello Drew,

looks like the original poster is using assembly references for solving the
problem you've touched.


Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Hi Philip,

I don't believe there's any cross-instance communication between
instances of your VS. Therefore, changes made to files by one
instance will be detected by the other instance. However, say you
have additional projects in your second instance, then any references
to modified names (for example) won't be changed, as the first
instance cannot see them.

I address this problem by loading all my projects in one solution, and
just changing the default project depending upon what I'm working on.

I hope that helps you.

Drew.



0
Comment actions Permalink

Dmitry,

Yes, I'm switching back and forth between the two. You're also correct on assemblies. That's how I'm using them.
I've attached the log from the second solution.
Here's the sequence of events:
1. Load solution 1
2. Load solution 2
3. Refactor in solution 1 (rename type, or chage interfaces)
4. Rebuild solution 1
5. Switch to solution 2
6. Replace all instances (case sensitive) of the old name with the new name
7. R# shows "Cannot resolve symbol"
8. Rebuild solution 2 (successfully)
9. R# still shows "Cannot resolve symbol"

I could've sworn I never had this problem in pre #254, but then again this situation was not that common.

Thanks.



Attachment(s):
tmp2416.tmp.ReSharper.1676.txt
0
Comment actions Permalink

Philip,

could you also please tell the name of the project containing the types being
modified?


Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Dmitry,

Yes, I'm switching back and forth between the two. You're also correct
on assemblies. That's how I'm using them.

I've attached the log from the second solution.

Here's the sequence of events:

1. Load solution 1

2. Load solution 2

3. Refactor in solution 1 (rename type, or chage interfaces)

4. Rebuild solution 1

5. Switch to solution 2

6. Replace all instances (case sensitive) of the old name with the new
name

7. R# shows "Cannot resolve symbol"

8. Rebuild solution 2 (successfully)

9. R# still shows "Cannot resolve symbol"

I could've sworn I never had this problem in pre #254, but then again
this situation was not that common.

Thanks.



0
Comment actions Permalink

Sure, my bad.

First project is FitUtils and the second project, the one I sent you the log from, is ShellFitLister.

Thanks.

0
Comment actions Permalink

I am noticing this also, and I am sure that it is something that has
recently started. We have utility classes in separate projects that are
modified much less often than the projects that use them and by another dev
team. The output dlls are put in a common area and all other projects
reference them from that area. Updates to the utility dlls used to be
picked up by R# when the solutions that referenced them were rebuilt and the
new dlls were linked.but that doesn't seem to be happening anymore.

"Philip Mateescu" <philip.mateescu@datacert.com> wrote in message
news:6236253.1153928507297.JavaMail.itn@is.intellij.net...

Dmitry,

>

Yes, I'm switching back and forth between the two. You're also correct on
assemblies. That's how I'm using them.
I've attached the log from the second solution.
Here's the sequence of events:
1. Load solution 1
2. Load solution 2
3. Refactor in solution 1 (rename type, or chage interfaces)
4. Rebuild solution 1
5. Switch to solution 2
6. Replace all instances (case sensitive) of the old name with the new
name
7. R# shows "Cannot resolve symbol"
8. Rebuild solution 2 (successfully)
9. R# still shows "Cannot resolve symbol"

>

I could've sworn I never had this problem in pre #254, but then again this
situation was not that common.

>

Thanks.



0
Comment actions Permalink

Hello Richard,

that's odd as nothing that might relate to the problem was altered in recent
builds. Could you also please
attach a log from VS that doesn't detect external changes and point out the
name of the project / assembly
that is being changed externally? Thanks in advance.


Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

I am noticing this also, and I am sure that it is something that has
recently started. We have utility classes in separate projects that
are modified much less often than the projects that use them and by
another dev team. The output dlls are put in a common area and all
other projects reference them from that area. Updates to the utility
dlls used to be picked up by R# when the solutions that referenced
them were rebuilt and the new dlls were linked.but that doesn't seem
to be happening anymore.

"Philip Mateescu" <philip.mateescu@datacert.com> wrote in message
news:6236253.1153928507297.JavaMail.itn@is.intellij.net...

>> Dmitry,
>>
>> Yes, I'm switching back and forth between the two. You're also
>> correct on
>> assemblies. That's how I'm using them.
>> I've attached the log from the second solution.
>> Here's the sequence of events:
>> 1. Load solution 1
>> 2. Load solution 2
>> 3. Refactor in solution 1 (rename type, or chage interfaces)
>> 4. Rebuild solution 1
>> 5. Switch to solution 2
>> 6. Replace all instances (case sensitive) of the old name with the
>> new
>> name
>> 7. R# shows "Cannot resolve symbol"
>> 8. Rebuild solution 2 (successfully)
>> 9. R# still shows "Cannot resolve symbol"
>> I could've sworn I never had this problem in pre #254, but then again
>> this situation was not that common.
>>
>> Thanks.
>>


0

Please sign in to leave a comment.