History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: RSRP-35339
Type: Bug Bug
Status: Open Open
Priority: Normal Normal
Assignee: Serge Baltic
Reporter: Nick Martyshchenko
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
ReSharper

Newly added resource identifiers recognized only after adding another identifier

Created: 07 Feb 07 17:57   Updated: 28 Aug 08 14:37
Component/s: VS integration
Fix Version/s: 4.5
Security Level: Everybody (All jira users)

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown
File Attachments: None
Image Attachments:

1. screenshot-1.jpg
(41 kb)

2. screenshot-2.jpg
(35 kb)
Issue Links:
Duplicate
 
This issue is duplicated by:
RSRP-38287 Resharper not detect app settings cha... Normal Closed


 Description  « Hide
Adding a new identifier into resource leads to the misrecognize by ReSharper's Intellisense. Newly added identifiers recognized only after adding another identifier into resource, which was also not immediately identified. Thus, IMHO change of the resource file is not processed at the right time.

 All   Comments   Work Log   Change History      Sort Order:
Nick Martyshchenko - 21 Feb 07 11:02
Just added resource identifier MSG_ERR_CANT_CHECK_REGISTRATION_INFO

Nick Martyshchenko - 21 Feb 07 11:09
Attempt to use identifier... Is there any solution? I always use resources for my strings, it is very annoyed bug for me. Also this bug appears while using Resource Refactoring Tool. Any suggestion?

Dmitry Shaporenkov - 13 Mar 07 16:29
Seems to happen if the Resources.Designer.cs file is not opened in the editor

Nick Martyshchenko - 19 Mar 07 12:35
Consequent rename the same identifier in resource editor able to resolve issue

Dmitry Shaporenkov - 22 Mar 07 14:35
Unfortunately, the problem causing this bug is that we don't get proper notifications about modifications of file Resources.Designer.cs which VS makes after adding a new resource. We'll discuss with MS this issue, may be there's a workaround we could implement

Nick Martyshchenko - 22 Mar 07 15:35
You can monitor for changes by yourself... Or something interfere with this solution?

Dmitry Shaporenkov - 22 Mar 07 15:46
I'm not sure what exactly you mean, but, delving more into details, we do monitor external changes (e.g. timestamps of files on disk). However, we ignore external changes for files that are opened in the VS in the sense that an in-memory buffers for them are maintained by VS (as it's up to VS to update its own buffer and notify us about these updates), and *.Designer.cs is opened in this sense. The problem is that we're not receiving notification about changes made by VS to this buffer.

Nick Martyshchenko - 22 Mar 07 18:03
I understand your explanation.. I talk about FileSystemWatcher class on *.Designer.cs since I noticed ReSharper did'nt aware any changes on *.Designer.cs made by tools for example Resource Refactoring Tool. I dont open *.Designer.cs in IDE manually and think VS didnt cache changes on it. Maybe Im wrong and when I open resource editor *.Designer.cs cached in background? I thought VS simply regen resource designer after any changes...

Dmitry Shaporenkov - 22 Mar 07 18:12
I looked into this and it appears than when the user goes to 'Properties' tab of the containing project and changes something there, VS 'opens' *.Designer.cs file (creates a buffer for it), and then modifies the buffer. The only problem is that it doesn't notify us about this activity, so we don't know that it's time to refresh our cached information.

Actually, ReSharper should be aware of external changes made to *.Designer.cs files but as I said earlier it could simply ignore them if it believes that the file is currently 'opened' in VS. I'll try it with Resource Refactoring tool and check why ReSharper ignores changes in that case


Nick Martyshchenko - 23 Mar 07 10:07
Thanks for explanation. RRT uses VS API so changes to *.Designer.cs made on internal buffers thats why ReSharper did'nt noticed it. Hope you'll find any suitable workaround.