How to correctly react on file change - c#

I'm writing a Visual Studio editor plugin. I'd like the editor to behave similarly to other editors: if the edited file changes outside the IDE, I want the proper dialog window to be displayed and the document reloaded (if needed).
The IVsPersistDocData interface contains methods IsDocDataReloadable and ReloadDocData, but during debugging, they were never called in this scenario.
There is a combination of IVsFileChangeEx and IVsFileChangeEvents interfaces, but reaction to changing files outside the IDE seems to be so generic, that I guess I shouldn't need to manually monitor the edited file. Or should I?

It seems, that there actually is no automatic mechanism for doing that and using IVsFileChangeEx and IVsFileChangeEvents seems to be the only solution.
http://blogs.msdn.com/b/dr._ex/archive/2005/11/01/487721.aspx
http://msdn.microsoft.com/en-us/library/Microsoft.VisualStudio.Shell.Interop.IVsFileChangeEx.aspx

Related

Resource Files not being Compiled into DLLs

I have a localized WinForms application. To avoid a large number of iterations in the translation procedure, I have given our translators software to allow them to edit the .resx files directly.
This has worked great for the resource files that are not tied to UI components (Forms/Controls), but for forms and Controls the resources don't seem to be getting updated. What I mean by this, is that at design-time all resource strings are correct (Text/ToolTips et al.) and I can see the correct translations - when I run the application (debug or any other release) the translations are not being updated, why?
Thanks for your time.
Edit1. The plot thickens further. There are two buttons that are not being updated at all when I change their components (button text, tooltip or any thing governed by the underlying resource file). Lets say I change the button text from 'Lock Workbook' to 'Lock Workbook GG', then the new text shows in the designer and the .resx files (both in the .resx designer and the code behind) but when I run the code (in debug or release mode) the button text is not updated!?
If I update the button next to the button I updated above, this does change the text in the running application?? This is baking my noodle as I fail to see where the old text is being stored and why for a sub-set of buttons their component text is not getting updated!?
Any ideas are warmly welcomed!
Edit2. I have tried to delete the .suo and clean and recompile. I have also removed the troublesome form from the solution and re added it.
So that you can see this strange behavior, here is one of the problematic buttons ('Lock Workbook GG') and a normal one ('Set as Default Workbook GG').
Now at run-time I see
Maybe your build settings are wrong?
This is what I have for my dll.
I have given our translators software to allow them to edit the .resx files directly
That certainly was not a good idea. Any professional translator will know how to tackle .NET resx files. Even if they don't have any of the tooling that's traditionally used by translators, like SDL Passolo, then they would still fall back to the standard Winres.exe utility included with the SDK.
Whatever you wrote probably has a bug. Quite hard to reverse-engineer from the question what that bug might be. Other than that the .resx file for a Winforms form is quite different from the one you get from Resource File project template or the resource designer. There are lots of resource naming tricks to avoid ambiguity between the form's properties and the properties of its controls. Get a name wrong and it won't work right.
Don't write your own, at least ask them to use Winres.exe if necessary. It is free.
The bindings to the button are made in the Designer File of the related form, have you checked whether there are some issues? Try removing the code that sets the ressource and re-add it via the designer.
Probably this has something to do with the CopyLocal property. Please check if these are TRUE for these resource files. If not, set them to true, otherwise, after succesfull compilation, they are not being copied to the output directory.

Get question mark instead property name and value in Debug Mode in Visual Studio

My issue is: during Debug Mode in Visual Studio I can not see property name and it value. Any suggestions? UPD This bug/feature is reproducible in college PC.
UPD(15.06.2012)
The base class is placed to separated lib. Base class is abstract. And... Two times Debug was working fine, after making changes in source file (in screen-shots) and then running the project.
Please notice that Immediate window can not evaluate this expression.
MailProcessingViewModelContext inherits that base class that I have mentioned in the top of UPD.
It's a bug in Visual Studio that's caused when you scroll through the properties list with a mouse. Click the down arrow at the bottom of the menu instead.
As somebody on top already mentioned, you need the debugging symbol files (.pdb's) for every dll that you are using which is not your code, otherwise VS can't look 'inside'.
and if it's obfuscated you won't see anything at all
This would happen if you were debugging an ASP.NET wizard and wanted to check a collection of something, all elements in the collection that are in the current wizard step (current context) would be visible while the others are there but not in context just now hence marked as questionmarks -> ?
Maybe it could be something like that in your case. I guess it could be the same scenario
For me, this happened when I had a getter property in a class model pointing to itself. It was a copy paste error, notice the property name is ShouldNotProcess, and in the getter it's returning itself. The return was supposed to be: return !this.ShouldProcess;
public bool ShouldNotProcess
{
get { return !this.ShouldNotProcess; }
}
Are you trying to debug your own code or someone else's?
If it's not your code, the code has probably been obfuscated so you cannot see the private members or use reflector to reverse engineer it.
This also might happen if you're using a trackpad to scroll through the member list. Try using the keyboard instead.
You cannot access these menu items or display these windows in design mode. To display these menu items, the debugger must be running or in break mode.
REF:
http://msdn.microsoft.com/en-us/library/bhawk8xd
Is there a possibility that the object you are referring to belongs to another project (library template) and you added it as a file reference and not project reference?
Please share the details about the structure of the projects in your solution. Also the location of the class you are trying to access.
Make sure you're running in debug mode, I know I'm probably stating the obvious there. Also, check that expression you're evaluating - is it right? Are you casting to the right object. Finally, is the assembly that contains the class you are looking at included as a project in the solution, or just referenced as an external assembly? Make sure it's part of the sln.
If it's recreatable on another copy of visual studio then I'd guess it's not a problem with Visual Studio, but the object you are looking at.
Not sure if this is the case in your situation, but here is a post with a similar issue. Hope it helps

Designer forcing resources to be embedded in form, rather than using Resources.resx?

This problem has left me scratching my head! I'll try to be as concise as possible.
On a high level:
The problem is that although the project works fine and the code looks good to me. Whenever I edit and build certain forms, Visual Studio re-writes the *.Designer.cs files in a way that is very undesirable.
I quite confident that these *.Designer.cs files have not been edited (especially the auto-generated portion) in the past.
In more detail:
Our project uses custom controls, some which inherit from PictureBox. On the forms where these controls are present, if I view the *.Designer.cs file, I either see that the Image property is not set, or the Image property refers to an image stored in the project's resx file like below, which is all well and good.
this.customButton.Image = global::MyProject.Properties.Resources.buttonImage;
However, if I simply modify this form by adding another control (drag another button onto the form) and build the project, Visual Studio extensively edits the MyForm.Designer.cs and MyForm.resx files, even for the existing controls on the form that were not touched. It seems that it embeds all the images needed by the controls in the MyForm.resx file and then refers to them in the MyForm.Designer.cs as follows:
System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(MyForm));
this.customButton.Image = ((System.Drawing.Image)(resources.GetObject("customButton.Image")));
This is obviously not what I want. Why does Visual Studio want the form to use a local resource now, instead of the one embedded in the project's Resources.resx file as it was happy to do before the form was modified? If I go to the designer, view the properties of the customButton, and try to set the Image property to the image in the project resource file, it allows it, but on the next click, it will immediately revert back to the local reference embedded in MyForm.resx.
Any ideas why this is happening?
I figured this out with the help of another question
Basically, even though I've seen several recommendations to centralize your application's resources in a single assembly, this appears to be a bad choice. The VS Designer just doesn't like having to access resources external to the current assembly and while it can do so, it will also change your code to bring those resources in the current assembly by embedding them, thwarting your efforts to keep the resources in a single assembly.
I basically had to go back to keeping resources in the assembly the uses them.

Debug mode works. Release mode generates ERRORs galore!

I have a solution that uses a native .DLL library that is wrapped by a .NET .DLL with a C# GUI.
All my plumbing works just fine in Debug mode. The moment I try going to Release mode, I get a whole whack of error messages, largely to do with the .CPP files in the native library. Errors include the following:
definition of dllimport function not allowed
TRACE_DEBUG_METHOD_CALL: identifier not found
a lot of undeclared identifiers in my main .CPP file (eg: DLLAPI_Release: undeclared identifier)
I have to admit that the Properties configuration for a C/C++ project is overwhelming so I wonder if there is one or more simple settings somewhere that I simply need to modify.
ALSO, is there a book out there that is devoted to the project properties window in VS2010 specifically? I have a few books but none really spend anytime on what is obviously a very crucial component to serious app development.
I appreciate any assistance anyone can offer. Thanks!
This is not unlikely to happen when you made a bunch of setting changes but didn't also make them for the Release build. Easy to forget, the first time anyway. You can easily tell which settings were changed from the default, they are displayed in bold type. Step through the setting pages, flip back-and-forth with the Configuration combobox in the upper left corner.
About 15 minutes of your life, not counting the thinking time you need because the setting should be different for the Release build. Start another instance of Visual Studio with a dummy project to verify that.
Trying to compare the property pages can be a beating. My recommendation would be to open the property pages for your project, select the Debug configuration, and under "C/C++", select "Command Line" and copy the command line options into a text editor, then do the same for the Release configuration and see where they differ. You'll need to do the same for the "Linker" command line.
Some of the differences will be intentional (e.g. debug flags should be set for the Debug configuration), but you should be able to spot things that should be the same but are not.
Actually tracking down where the command line options are set can be a bit of a pain, especially if you are using property sheets to manage common properties between projects, but generally you should be able to track them down just by looking through the different options on the different pages.
As for a reference, the best reference is the actual compiler documentation on MSDN. There is a section containing all of the documented compiler options and one containing all of the documented linker options.
The property pages are just a GUI frontend for setting these various options. When you select one of the properties in the property pages, it should say in the help box at the bottom of the dialog which compiler options are used by that property.

Trouble in Visual Studio 2010, changing resources is setting the constructor to internal

I am experiencing some weird behavior of Visual Studio 2010 when developing Silverlight applications and using project resources (.resx)
Everytime I change a resource it sets itself to internal instead of public in the code behind, altough I can see it in the design mode as set to public it is not.
Any idea how to fix this?
I don't know if this affects only Silverlight projects or generaly all C# projects.
This link might help.
http://blogs.msdn.com/b/silverlight_sdk/archive/2010/09/08/ach-du-lieber-a-tour-of-some-localization-gotchas-in-silverlight.aspx
It says:
Turns out there's a flaw in the VS
build action logic here; unfortunately
changing this tool action will NOT
flip the access level of the class
constructor from internal to public
(at least not for a strongly typed
language). A public constructor is
another requirement of Silverlight
XAML usage of a class. You will have
to do this yourself manually in the
designer.cs file.
Hope this helps
EDIT:-
Here's another one http://www.wintellect.com/CS/blogs/jprosise/archive/2010/06/21/dynamic-localization-in-silverlight.aspx that says
Finally, Visual Studio suffers from a
long-standing bug that leaves the
constructor of the ResourceManager
wrapper class it generates marked
internal when you change the class's
access modifier to public. This means
that whenever you modify the primary
RESX file, forcing a code regen, you
have to manually change internal to
public on the constructor in the
generated code. It beats me why this
hasn't been fixed after all these
years, but it hasn't.
My approach consists in configuring a pre-build event that replaces "internal" with "public" in your .Designer.cs file. I have a post on my blog about the whole process, from creating the localized string to binding them and configuring the pre-build event command line.
The hearth of the process is to get a text-file replace utility (say it's called REPLACE.EXE) and set a pre-build action like this:
c:\utility\replace\replace.exe "$(ProjectDir)\LocalizedStrings.Designer.cs" "internal" "public"
$(ProjectDir) is a VS built-in macro that returns the path to your project folder.
I also gave an example of such a simple replace utility source code on same post.
The best solution is to switch the tool used to generate the resource code behind .cs file to one the automatically outputs the constructor as public instead of internal. The best one I have found is from Guy Smith-Ferrier. Download and run the installer and then change the "Custom Tool" property of your .resx resource file to "PublicResourceCodeGenerator".
Workaround:
Inherit another class from the generated one
public class TextRes2 : TextRes
{
public TextRes2() { }
}
and use that instead of the original
<ResourceDictionary>
<!--res:TextRes x:Key="Strings" /-->
<res:TextRes2 x:Key="Strings" />
</ResourceDictionary>
There's a problem with all of these solutions - at least in our case.
Our resource files are all modified by a 3rd party codegen tool which updates the resource files to match the changes made in the UIs. All it does is update the strings in the xml. we still have to go in to the VS and toggle the Access Modifier from Public to something else, and back to Public so VS will synchronize the code-behind to match the new string values. THEN we have to update the c# by changing internal to public.
So for us, we need both steps automated, rebuilding the code behind and the fixing internal.

Categories