You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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)
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):
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.
The text was updated successfully, but these errors were encountered: