Skip to content
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

ColorPicker use default InitializeComponent() method instead SpecialInitializeComponent() as other controls in ICSharpCode.WpfDesign.Designer #109

Closed
MihailRomanov opened this issue Jan 15, 2024 · 4 comments

Comments

@MihailRomanov
Copy link

Perhaps this wouldn't be a problem, but now during the release process, the version number is in the format Major.Minor.Build, and in some places it is used in the form of 3 digits, but for the assembly version it is extended to Major.Minor.Build.Revision.

As a result, it turns out that, for example, for version 8.1.45 (the latest version on nuget.org):

  • the locator for ColorPicker in the InitializeComponent() method is specified in the format "/ICSharpCode.WpfDesign.Designer; V8.1.45; component/controls/colorpicker.xaml"
  • if it is not found, start search assembly by name "ICSharpCode.WpfDesign.Designer, Version=8.1.45, Culture=neutral"
  • but in reality, the assembly has a full name "ICSharpCode.WpfDesign.Designer, Version=8.1.45.0, Culture=neutral, PublicKeyToken=null", and search by FullName fails

Again, this is not a problem if the ICSharpCode.WpfDesign.Designer assembly locate in the same directory as the program (then the search by non-strong name and everything is OK), but in the case, for example, as in SharpDevelop, where the assemblies place in a separate directory - it is a problem.

I checked that switching to SpecialInitializeComponent() in ColorPicker solves the problem. If necessary, I can prepare a PR.

@jogibear9988
Copy link
Member

Yeas, would be nice to prepare a PR.
I think the main purpose of the SpecialInitializeComponent was, that the Designer could be used to develop the Designer. This was a usecase when Sharpdevelop was used to develop Sharpdevelop

@MihailRomanov
Copy link
Author

Yes, it seems so. The main purpose of the SpecialInitializeComponent is to support multiversioning.

It just so happens that in my case it also solves the problem with assembly cache in SharpDevelop (it's a fairly straightforward mechanism, and it's probably worth revisiting it in the future, but right now I don't want to waste time on it)

@MihailRomanov
Copy link
Author

@jogibear9988 Could you publish new NuGet package version (with this fix)?

@jogibear9988
Copy link
Member

done
thx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants