共享资源，图像和设计师 [英] Shared resources, images and the designer

问题描述

大家好，
我们的应用程序包含几种解决方案.它使用MEF插入功能部件，一切都很好.

我现在尝试找到一种在所有这些项目中共享资源的方法.
当前，我创建了一个DLL，其中包含一个公共资源文件，该文件托管我所有其他项目中需要的图像.
我引用了包含资源文件的dll，然后可以从代码访问所有图像.

有没有一种方法可以使设计人员支持这种引用的rersource dll?
我想在设计器中选择图像，而不要操作Form.Designer.cs或通过代码自己对它们进行初始化.

我也尝试从Resource.Designer.cs继承，但这也没有解决.我可以访问图像，但是只能从代码访问(每次我从继承的资源文件中添加/删除元素时都会重新生成图像-这不会是一个大问题，因为从逻辑上讲不应更改)

任何帮助，感激不尽，
欢呼
Andy

Hi all,
Our application consists of several solutions. It uses MEF to plugin functional parts, that is all fine.

I now try to find a way to share resources across all of those projects.
Currently I create a dll containing a public resource file hosting images I need in all of my other projects.
I reference the dll containing the resource file and I can access all of the images... from code.

Is there a way to have the designer support such a referenced rersource dll?
I''d like to select the images in the designer and not manipulate the Form.Designer.cs or initialize them myself from code.

I also tried to inherit from the Resource.Designer.cs, but that also didn''t work out. I can access the images, but again only from code (beside the fact that it is regenerated every time I add/remove elements from the inheriting resource file - which won''t be a big problem because logically it should not be changed)

Any help is kindly appreciated,
cheers
Andy

推荐答案

资源被设计为程序集的内部资源.但是，这个问题是可以解决的.您需要将所有资源放入一个或多个特殊的仅资源的程序集中，并提供专门用于将资源公开给引用您的资源程序集的程序集的特殊外观类(或多个类).暴露的一种典型形式应该是静态类的公共静态属性.

(请参见 http://en.wikipedia.org/wiki/Facade_pattern [Image.许多其他资源类型也是如此.您不必使用资源流，读取或转换任何内容；您已经有一个完全初始化的静态Image.对于文本文件，则为字符串，或其他.

到目前为止，还不错，但是唯一的问题是，当您使用许多图像文件时，使用资源的代码编写者应该使用语义(希望)变量名(很好，不是字符串，因为编译器无法检查它们)拼写正确)，但是如果太多的话该怎么办?对许多资源的访问不是结构化的.

当您在我的方法中有一个Facade类时，就可以使用额外的灵活性来重构访问.例如，您可以根据语义标准将这些图像变量分组为某些结构，甚至可以将它们呈现为按枚举类型索引的集合和/或按枚举类型索引在循环中枚举.

(顺便说一句，您可以从我的文章中了解如何通过枚举类型索引进行枚举:

Resources are designed to be internal to the assembly. However, the problem is solvable. You need to put all resources in one or more special resource-only assemblies and provide a special facade class (or classes) used exclusively to expose the resource to the assemblies referencing your resource assemblies. A typical form of exposure should be a public static property of a static class.

(See http://en.wikipedia.org/wiki/Facade_pattern[^].)

For one thing, this will present a certain maintenance hassle: as soon as you change or add a new resource, you will need to change the facade class: add a property or modify the implementation of existing property, usually just a name if internal property. Also, it looks like a functional redundancy. (But do you have a choice without redundancy?)

From the other hand, the facade class is trivial, maintenance is not tricky, and it can give you a layer for additional flexibility, so the interface can be done in a more semantic style from the perspective of the referencing assembly (user assembly). I can explain.

For example, you need to add N images. The best way of doing it through the designer is this: you add the *.res resources using the Designer as separate image files using "Add existing file". The designer will copy the file in the project directory structure (make sure it would not produce double copies, you only need to keep the target copy in the project), add the reference file to the project file with appropriate attributes (instructing the MSBuild: embedded resource, don''t copy to the output directory), it will also add the reference to the file to the resource file and — important — will auto-generate the source file. Look at this source file: you will find some static class and some static property with the name close to the name of the image file. The best thing is: if the file type is JPEG or PNG, the type of the static property is Image. Same thing with many other resource types. You don''t have to use resource stream, read or convert anything; you already have a fully-initialize static Image. Or string in the case of the text file, or something else.

So far so good, but the only problem is when you use many image files, the writer of the code using the resources should use the semantic (hopefully) variable names (very good that not strings as the compiler would not able to check it they are correctly spelled), but what if there are too many? The access to the many resources is not structured.

As you have a facade class(es) in my approach, you can use the extra flexibility to restructure the access. For example, you can group those image variables into some structures by semantic criteria or even present them as a collection indexed by an enumeration type and/or enumerate in a cycle by a enumeration-type index.

(By the way, you can learn how to enumerate by a enumeration type index from my article: Enumeration Types do not Enumerate! Working around .NET and Language Limitations[^].)

—SA

这篇关于共享资源，图像和设计师的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！