By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,124 Members | 1,566 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,124 IT Pros & Developers. It's quick & easy.

What to do when numeric resource ID is required in .NET?

P: n/a
Several attributes and interface methods I'm using refer to resources (such
as strings or icons) by a numeric ID. This was the only way to refer to
resources in unmanaged code (C++, for example), but I'm writing in C# now,
and it seems that resources are named with string identifiers.

Visual Studio doesn't seem to like resource names such as "100", so I'm
wondering how this could work. Is it absolutely necessary for me to have a
satellite DLL project which uses the old .res (unmanaged) resource format?

Confused...

-Scott
Oct 3 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
"Scott Smith" <paul@nospam_colton.net> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
Several attributes and interface methods I'm using refer to resources
(such as strings or icons) by a numeric ID. This was the only way to
refer to resources in unmanaged code (C++, for example), but I'm writing
in C# now, and it seems that resources are named with string identifiers.

Visual Studio doesn't seem to like resource names such as "100", so I'm
wondering how this could work. Is it absolutely necessary for me to have
a satellite DLL project which uses the old .res (unmanaged) resource
format?

(snip)

OK, I think I've resolved this. For those who are curious, here's a
clarification of the problem, followed by the resolution...

There is an attribute that you can apply to your
Microsoft.VisualStudio.Shell.Package derived class:

[Microsoft.VisualStudio.Shell.PackageRegistrationAt tribute(UseManagedResourcesOnly
= true)]

This says that you're not going to be referring to resources such as strings
in an unmanaged satellite DLL. Instead, strings, icons, bitmaps, what have
you, are going to be in your assembly as managed resources.

So then, when you implement the IVsInstalledProduct interface in your
Package-derived class, you're faced with implementing methods such as the
following:

public int IdIcoLogoForAboutbox(out uint pIdIco)

....but managed resources are identified by strings. Perhaps the caller of
this method (or the resource loader that it's using) will convert this
integer into a string (e.g loading a resource named "101").

This seemed reasonable, and the "...\Visual Studio 2005
SDK\2005-09\VisualStudioIntegration\Samples\IDE\CSharp\Refe rence.Package"
sample does exactly this. It has several string resources, a bitmap and an
icon, all named using a number like "101".

Whenever I tried to name a resource with an identifier like "101" in my
solution, it generated an error saying something like "the identifier must
start with an alpha character, or underline". I even tried copying the XML
contents of the .resx file from the sample project into my Project's .resx
file. I still got the errors.

I was convinced at that point that there must be some kind of flag or
setting in one project that wasn't present in the other. After a
side-by-side comparison, looking at the properties for my .resx file, I
found it in the "Custom Tool" property:

Custom Tool ResXFileCodeGenerator

Not sure whether this is something new to VS 2005, but this creates a new
class ("{your-resx-filename}.Designer.cs") with type-safe properties to
retrieve every resource in your .resx file, e.g.:

internal static string _101 {
get {
return ResourceManager.GetString("101", resourceCulture);
}
}

....the property name ("_101") is based on the resource name, and as you can
see, if your resource name is numeric, the result is an invalid C# property
name. If you set the "Custom Tool" property to empty, the generated
....Designer.cs file goes away, and Dev Studio doesn't complain about the
resource names any more.

-Scott Smith
Oct 4 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.