When upgrading to UI for WPF R3 2021 (NuGet), we are unable to build our projects because of a broken reference to Microsoft.VisualStudio.DesignTools.Extensibility. We also noticed that for each dll, a corresponding *.DesignTools reference was added to the project when we did the update - maybe there is a connection?
How to reproduce
I was able to reproduce the problem by creating a new .NET Framework app (default VS template, .NET Framework 4.8) and adding the Telerik.Windows.Controls.for.Wpf nuget package (see attached screenshot). As soon as the package is added, I get the following IntelliSense warning:
Severity Code Description Project File Line Source Suppression State
Warning Unknown build error, 'Could not load file or assembly 'Microsoft.VisualStudio.DesignTools.Extensibility, Version=16.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)' WpfApp5 Build
When trying to build the project, I get the following error:
Severity Code Description Project File Line Source Suppression State
Error Unknown build error, 'Cannot resolve dependency to assembly 'Microsoft.VisualStudio.DesignTools.Extensibility, Version=16.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.' WpfApp5 Build
Manually adding the nuget package "Microsoft.VisualStudio.DesignTools.Extensibility" resolves the problem.
I would expect the telerik packages to reference the mentioned package as their dependency if it is required (allowing Visual Studio to resolve the missing reference automatically). If this is not possible for some reason, this should at least be noted in the documentation.
Regards
Simon Müller
Hofmann Fördertechnik GmbH
Hi,
This issue was referenced all the way back in 2017 in this post for Win Forms, but it appears it was never actually resolved; only a workaround was provided. I don't think this workaround will work for me, however, because I am binding to the RtfDataProvider in xaml and therefore it makes the changes to the document string before I am able to do a manual replacement of "rtf1" where it only had "rtf" for the version tag before. While changing the tag after the fact will fix the issue of it not being recognized in the other software we use, it still causes bloat because of the fact that it most cases it over triples the amount of raw text in the returned string when the textbox does not properly apply the rtf version tag.
Below is an example of the greatly enlarged amount of data before and after this error occurs:
"S11111^A^1^","{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fcharset0 Arial; } }\viewkind4\uc1 \f0\fs20 Measurements: \par \tab Neck to Fundus \tab \tab 1.5 cm \par \tab Diameter at Fundus \tab \tab 3.0 cm \par \tab Color \tab \tab \tab \tab Green-Tan \par \tab Wall Thickness \tab \tab 1.0 cm \par \tab Mucosa \tab \tab \tab Velvety \par \par No Cholesterolosis Is Identified \par \par No Bile Identified \par \par No Gallstones Are Identified \par \par Summary of Sections: \par \tab Received in Bag and Formalin. The cystic duct margin and representative sections of gallbladder fundus and body are submitted in 1 cassette. \par \par KG/sjh }"^""$$$"
"S11111^A^1^","{\rtf\ansi\ansicpg1252\uc1\deff0\deflang1033{\fonttbl{\f0 Verdana;}{\f1 Arial;}}{\colortbl\red0\green0\blue0 ;}{\*\defchp\ltrch\f0\fs20\i0\b0\strike0\cf0\ulc0\ulnone}{\*\defpap\sl276\slmult1\ql\sa180\ltrpar}{\stylesheet{\s0\sqformat\spriority0\ltrch\f0\fs20\i0\b0\strike0\cf0\ulc0\ulnone\sl276\slmult1\ql\sa180\ltrpar Normal;}{\*\ts2\tsrowd\spriority59\trbrdrt\brdrnone\trbrdrb\brdrnone\trbrdrl\brdrnone\trbrdrr\brdrnone\trbrdrh\brdrnone\trbrdrv\brdrnone\trgaph0\trpaddl75\trpaddr75\trpaddt0\trpaddb0\clpadft3\clpadt0\clpadfr3\clpadr0\clpadfl3\clpadl0\clpadfb3\clpadb0\tsvertalt\ltrch\f0\fs20\i0\b0\strike0\cf0\ulc0\ulnone\sl276\slmult1\ql\sa180\ltrpar Table Normal;}}\nouicompat\viewkind4\paperw12240\paperh15840\margl1425\margr1425\margt1425\margb1425\deftab720\sectd\pgwsxn12240\pghsxn15840\marglsxn1425\margrsxn1425\margtsxn1425\margbsxn1425\headery720\footery720\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone Measurements: }{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone \tab Neck to Fundus \tab \tab 1.6 cm }{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone \tab Diameter at Fundus \tab \tab 3.0 cm }{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone \tab Color \tab \tab \tab \tab Green-Tan }{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone \tab Wall Thickness \tab \tab 1.0 cm }{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone \tab Mucosa \tab \tab \tab Velvety }{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone }{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone No Cholesterolosis Is Identified }{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone No Bile Identified }{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone No Gallstones Are Identified }{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone Summary of Sections: }{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone \tab Received in Bag and Formalin. The cystic duct margin and representative sections of gallbladder fundus and body are submitted in 1 cassette. }{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}\pard\sl240\slmult1\ql\ltrpar{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone KG/sjh }{\ltrch\f1\fs20\i0\b0\strike0\cf0\ulc0\ulnone\par}}"^""$$$"
If there is a way that I can use the workaround in that post to prevent this bloating of the data while still using my current setup with bindings, I would be happy to do so, but as it is I don't think that's the case. It seems like this is clearly a bug and something that should have a real fix on the control and not a workaround after all this time, but if that's not the case and it was left as is for a reason, I'd be happy to hear that reason.
Thanks in advance for the help.
Is there a workaround for this or is this a bug that you will fix?
Hi,
I found a bug when drag&dropping selected tree nodes (extended multi-selection) when the tree is virtualized. Items that never got into view are missing from the Payload Manager Data object. If virtualization is off, works as expected.
Please see modified sample for demonstration. I added 200+ items to League A -> Division A. Select the first item, quickly scroll by dragging vertical scrollbar to the bottom of the list and extend selection to the whole list. Then perform drag and drop. Note, not all items were moved.
Also, the drag visual helper moves and updates very very slowly when dragging hundredths of objects. In our application, we have thousands of objects, which makes it unusable
Thank you for a quick fix.
Tomas.