开发者

Hook the resolution of assemblies and types loaded in a Xaml context

开发者 https://www.devze.com 2023-04-12 08:41 出处:网络
for a good reason we are prefixing our assemblies, with a prefix specific to each application : e.g. if we have a project named \"A\" which is a dependency of an application named \"MyApplication1\"

for a good reason we are prefixing our assemblies, with a prefix specific to each application :

e.g. if we have a project named "A" which is a dependency of an application named "MyApplication1" the latest will use a "MA1.A" assembly generated at build-time;

if another application "MyApplication2" has also a dependency on "A" we will transform the output of "A" as "MA2.A" when building the application...

So far so good.

Now we are starting to use WPF and we need to reference some types of "A" in the Xaml :

xmlns:a="clr-namespace:Some.Name.Space;assembly=A"

This is fine at design-time but at runtime there is no more "A" assembly but a "MA1.A" or "MA2.A" assembly, so开发者_如何学C the application crashes.

Do you have any idea to workaround this issue without affecting too deeply the development process ?

E.g. loading the Xaml by hand and setting the prefix is not an acceptable solution.

Thanks in advance for any idea.


The .NET run-time needs to know what assemblies your assembly depends on. That is why you refer to the assemblies in code so the run-time knows where to find the class(es).

If you decide to rename the classes you will have to inform the CLR of the rename action.

The only way I see is by editing the source code or redirecting at run-time but WPF doesn't like that

for a good reason we are prefixing our assemblies

As much as I would like to believe you; I strongly suggest that you keep the names at compile time equal to the run-time version. It will be much easier to debug and trace errors. But as you didn't mention the reason I might be wrong here.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号