-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assembly version in Xaml/Baml resource is removed #205
Comments
After examining this issue for a while, I have an idea on how to resolve this. From what I can tell, the modification is made in
Specifically, I think I can change I tried making this change and it does seems to resolve my issue in my test application. I haven't tried it on my full application yet. However, I get one failing test, which I also haven't had a chance to look into yet:
I understand this only affects a narrow set of cases like side-by-side loading that I am trying to do, but if it's useful I can create a pull request for the change. |
@mzboray How are you loading multiple versions of the same assembly? AFAIK this scenario is not supported in .NET (i.e., it will use latest version) But regarding the fix itself, I think I used the simple name without a specific reason. If the assembly is not signed, you won't have the assembly version in the namespace. I just tried making I think we can use the full version, but since it will be merged, in the end we'll need to represent the own binary in which we merge it. |
@timotei Loading multiple versions of the same assembly is definitely supported in .NET in general. It requires that you strong name all assemblies which we are doing. In WPF/XAML, in particular, you need to include assembly version information the generated code which is not done normally, but can be forced using the AssemblyVersion property in the csproj file described here. Ok it's good to know that there was not a specific known reason to only use the simple name. After some experimentation, I found that said test does not fail if I use just the assembly name and version. I'm not sure why the full name causes a failure. My initial concern was that this seemed like a bug only because resources that do not need to be modified are in fact modified. In my case, I am only merging in some helper classes from another dll. No Baml resources should need modification. |
@mzboray I tried reproducing this on the scenarios integration test: #209 However, it doesn't seem to work as expected, and I have done this:
|
@timotei I believe this case is slightly different. In my case I have 3 assemblies:
My issue comes from the fact that after merging assembly 2 and 3. The version number information in assembly 2's xaml resources referring to itself are no longer there. This assembly loads fine by itself. However if it is loaded side-by-side with a later version of itself there are various exceptions like InvalidCastException. If you still can't repro, perhaps tomorrow I can create a repo with a demostration project I used for basic testing before deploying it on our application. |
@mzboray I'd like to get a repro project, thanks! |
@timotei See my repo with the demo code: https://github.com/mzboray/DemoWpfSideBySide |
Is this now resolved or still a problem? I am having issues with missing resources |
I've been using ILRepack for combining some assemblies that have baml resources, and I have a need to be able to load two different versions of the same assembly. However I'm noticing that after running ILRepack on an assembly with baml resources the assembly versions are removed from the resource. I believe this causes the .NET runtime to load an incorrect assembly version in side-by-side scenarios throwing various exceptions (invalid cast or type not found).
Here is the decompiled baml in a non-ILRepacked assembly (via ILSpy)
Here is the decompiled baml in an ILRepacked assembly:
Note how the xml namespace uc has been modified. These types are all in the main assembly.
The text was updated successfully, but these errors were encountered: