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

Question

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

Closed this issue 10 months ago · 4 comments

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 commented 10 months ago

done
thx

👍1

Answer 1 · 2024-01-15T21:23:50.000Z

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

Answer 2 · 2024-01-16T10:27:36.000Z

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)

Answer 3 · 2024-01-16T16:35:11.000Z

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