I'm working with WPF and Telerik controls. I encapsulated RadPDFViewer inside ControlTemplate (I did that before for RadGauge and it works good), after I added all the required assemblies.
In the designer(user control) I can see the component as a gray rectangle but when I run the application it gives me error as u see in the attached file and it doesn't show me the component.
When I use RadPDFViewer not inside the ControlTemplate, in regular window it works fine.
Why only 'Telerik.Windows.controls.FixedDocumentViewers' can't be loaded (BTW all my assemblies) are the same version.
Thank you
The error you are getting is obviously around missing dependencies. The information you have given is not enough to respond with a definitive answer. So I will give you a best guess
You need to ensure that you copy to the output folder the assemblies Telerik.Windows.Controls.FixedDocumentViewers has a reference to. Not all references will be required as .net only loads assemblies when it requires them.
I will assume you are using the standard binaries and not the noxaml binaries.
So, using JetBrains dotPeek (a free .net decompiler), I got the following.
Telerik.Windows.Controls.FixedDocumentViewers has a dependency on the following
Telerik.Windows.Control,
Telerik.Windows.Documents.Core and
Telerik.Windows.Documents.Fixed
Telerik.Windows.Documents.Core has a Dependency on
Telerik.Windows.Zip.
and Telerik.Windows.Documents.Fixed has a dependency on
Telerik.Windows.Documents.Core
All of the assemblies has references to the usual suspects.
Since you appear to be playing with PDF files, you may need to load Telerik.Windows.Documents.FormatProviders.Pdf and if so, it has a dependency on
Telerik Windows.Documents.
and the other dependencies are mentioned previously.
To solve your problem, I would add the first 3 to your solution (Telerik.Windows.Controls is probably already added), and then add each of the other assemblies in turn until you find what you require.
I hope this helps.
In the VS Solution Explorer, right-click the Reference and make sure Copy Local is set to True.
I solved it. It's huge solution so I have to add this assembly to the startup project.
Thanks a lot
Related
We are developing plugins to be added to a giant & awesome software. We often reuse the same WPF controls so we packaged them and created separate assemblies for each of them.
Sometimes, we need to load 2 different plugins within the same instance of the software. At that point, if the 2 plugins use the same reusable control but with different DLL versions, WPF doesn't seem to be able to choose the correct one. Both DLLs are correctly loaded (seen using Process Explorer).
What we already tried :
Binding redirects
Assembly redirects
Overridden assembly resolving
Is there any solution to indicate to WPF which version of the same DLL it needs to select for requested namespace in XAML ? Could we force the use of the latest in some way (this would work for us) ?
Look at my commit o SharpDevelop: https://github.com/icsharpcode/SharpDevelop/commit/b3ea4a0efb7e3b8e083f8be40ea6f7e03ff44604
I fixed this, by using a custom "InitializComponent" Call! ("SpecialInitializeComponent") and using special merged ResourceDictionarys: VersionedAssemblyResourceDictionary! Hope that helps you!
This seems like it should be pretty simple but I can't seem to make it happen. Lets say I have an existing project with a user control named uc1. I would like to use this user control in another project. I right-click the project name in the solution explorer and select add>existing item, change the drop down to all files and select the files uc1.xaml and uc1.xaml.vb. This of course adds the files to the project but there is no correlation between the xaml and the code behind file and there is no way to use the control. What is the proper way of doing this?
Reed's answer is a good architectural one. If you plan on creating a control that you will reuse in many projects then it's best to use a control library.
Your original question is valid in some situations though. Say you have some source code from the Internet that you've unzipped to your drive. This project contains a .XAML file and its linked .vb file that you want to add to a project.
As you seen, the Visual Studio Solution Explorer doesn't link the files when adding with the "Add Item" dialog. I think this is a bug. I find that if I reload the project, the affiliation is added.
Here's a workaround I use. I drag the files from Windows Explorer /File Explorer onto the project in Solution Explorer. That works correctly the first time.
This of course adds the files to the project but there is no correlation between the xaml and the code behind file and there is no way to use the control. What is the proper way of doing this?
Normally, you'd add a reference to the other project, and use the UserControl directly.
This allows you to build a single project with your UserControl, and use the resulting assembly (DLL) in multiple projects without duplicating the code.
If you want to reuse your user controls you need to create a new project and choose "Class Library" from the list of available projects. When compiled this class library can easily be used by any number of other projects and solutions simply by adding a reference to compiled DLL created when you build this class library.
Edit: As mentioned in other answer it's "WPF UserControl Library", not simple "Class Library"...
You just need to add the .xaml file and VS should auto add the code behind(nested). I've seen this not work a few times and as #Walt Ritscher said this is probably a bug.
I found simply restarting Visual Studio and reloading my solution worked.
WPF is great in that I should be able to use {StaticResource MyBackground} instead of "White" throughout my app, and then by changing resource definitions redefine the look of my entire application.
Problem is Expression Blend just won't work if you have references to global resources in a subcontrol. Is there any other way of theme-ing your app? I am not willing to lose Blend designer support, or replicate a piece of code/xaml in every single control. I find it astounding that they have not fixed a bug of this magnitude.
Any ideas?
Cheers
So I haven't tried this, but it sounds like it would work. Also, the information is a bit dated. Please do let me know if it solves the problem. :)
From the Blend blog, add the following two chunks to your project files:
<DesignTime Condition="'$(SolutionPath)'!='' AND Exists('$(SolutionPath)')">true</DesignTime>
….
<ApplicationDefinition Condition="'$(DesignTime)'=='true' AND '$(BuildingInsideVisualStudio)'!='true' AND '$(BuildingInsideExpressionBlend)'!='true'" Include="App.xaml">
<Generator>MSBuild:Compile</Generator>
<SubType>Designer</SubType>
</ApplicationDefinition>
Basically this includes your app.xaml conditionally into your project so it gets used at design time, but not at build time. I'm guessing they assume people use msbuild to produce production code rather than clicking the build compile button.
Seems like this bug disappears if you use DynamicResources instead.
Explained here in b): http://blogs.msdn.com/b/unnir/archive/2009/03/31/blend-wpf-and-resource-references.aspx
Someone posted this link in an earlier SO question on the same bug, but for some reason it got no upvotes and was lost below other answers.
I have a winform usercontrol than I want to add to wpf project.
I added the relevant references (WindowsFormsIntegration, SystemWindowsForms and my user control dll) and added this row in my XAML:
xmlns:MyControl="clr-namespace:xx.xx.xx;assembly=xx.xx"
And then this:
<WindowsFormsHost><MyControl:control></MyControl:control></WindowsFormsHost>
When I write "MyControl:" the "control" is automated show up that mean VS recognize the control and all references added ok... but when I compile the project this give me the error in the title.
Edit
Its very strange when I'm compile the all project i've got error "The type or namespace name "xx' could not be found..."
but I added all the refernces and the VS recognize the namespace so why the compiler don't found them? If this problem will be solved I beleive the other problem also will disappear.
The solution is: Go to your project properties and change the Target Framework from Client Profile to the full version of the .Net you are using, see the image below. This problem happens if your DLL targets the full .NET Framework, and your WPF Application (main project) targets .Net Client Profile.
This happened to me when I included the assembly name in the namespace definition, but both controls were in the same assembly. Just removing the assembly part of the namespace declaration solved it.
Visual Studio will load the reference only for reflection so it will show correct intellisense correctly. But in order to compile, compiler will need all the dlls that your referenced dll is dependent on. So visual studio will show intellisense for mycontrol as it can find it in reference. But your myontrol may reference other dlls which you may not have added. You will have to add dependent references of mycontrol in your project too.
It could also be that the target framework is different between your projects. We host a class library dll with the WPF pages, and it was targeted to 'Any CPU', but the host application was targeted to 'x86'. Once they matched, the problem went away.
I ran into the same "The type or namespace name 'xx' could not be found..." issue.
It disappears when I moved my Visual Studio files on a local drive. They were stored on a shared network directory before. I dont know the root cause of this, but at least I can have my designer running now.
I've encountered this problem before and replacing <MyControl:control></MyControl:control> with just <MyControl:control/> fixed it for me.
No idea why though. It seems like the first form is only for controls which can contain other controls.
Quick intro: I have some Silverlight 1 content that people have been editing and putting into HTML pages. Unfortunately, this means a lot of repetative creation of Storyboards, etc. We can use Silverlight 2, but not everyone here is familiar with C#/has Visual Studio. What I would like to do is create some custom controls in C#, output to a DLL, then reference the DLL in the XAML file (just as if it was part of a Silverlight project in VS).
I've tried adding this:
xmlns:mycontrol="clr-namespace:MyControl;assembly=../../content_GLOBAL/controls/MyControl/MyControl"
in the Grid tag that is my root. I know the path to MyControl.dll is correct. When I actually try and use it, though (I add <mycontrol:MyControl></mycontrol:MyControl> to the grid) and I get a parser error. It all seems OK if I don't add the control, even if I leave in the xmlns.
I suppose on some level, this makes sense--looking for an assembly is useful if you are going to build something, and since this XAML isn't in VS, it isn't actually building anything. Is there another way that I can reference, and use a custom control in SL2 in a stand-alone XAML file?
Let me first make sure that I understand you correctly: You have a Silverlight app that doesn't use any managed code and is not packaged in a .xap file. The <object> tag refers to a loose xaml file.
This is the Silverlight 1 app model and can still be used in SL 2, and such apps are referred to as "v1-style apps" (even though they target SL 2 and may use features not present in v1). When an application in this form is used, the Silverlight plugin does not load any of the managed components of the runtime (e.g. the CLR, etc.), so referencing a dll from a v1 style app is not going to work.
However, there might be work-arounds to the challenge you are facing here. One solution might be to use a v2 style app that is packed into a .xap and uses managed assemblies. One of the reasons you gave for not doing this is that other developers one the team are not familiar with C#. This should not be an issue as C# is not a requirement for building apps in SL, you can continue to program against it in JavaScript. And if you are just writing JavaScript code, Visual Studio is not a requirement, since there is nothing to compile. They can just edit the .html/.js files and use the .xap/.dll files that were already compiled. Does this make sense?