I have a situation while developing a WPF MVVM application. After some extensive searching I'll try to explain the experienced behaviour on SO, and hope someone has a solution.
The WPF application under development, has a reference to a local developed "Infrastructure" assembly. This assembly mainly consists of classes to commmunicate with our WCF services.
This assembly has a assembly reference to a second assembly, "Ninject.Extensions.WCF", whoose content is used in some functionalities.
When I include a reference to the "Infrastructure" assembly, i get a VS2010 designer error that it cannot find the "Ninject.Extensions.WCF" assembly within a couple of seconds after triggering a local build.
This all makes sense because the designer "probably" traverses all referenced assemblies for definitions.
In this particular case, the assembly it's trying to load has nothing to do with WPF, so I can live with the designer not trying to resolve the assembly.
Is there a way to "tell" the designer to ignore these missing referenced assemblies instead of throwing an exception?
Related
I have a WPF appliation which uses the WPFToolkit.Extended from Codeplex for some controls.
The project file of the WPF application contains a reference to the WPFToolkit.Extended assembly.
For deployment purposes I'd like to have all assembly references for the WPF application which I query with Mono.Cecil:
assembly.SelectMany(asm => asm.Modules).SelectMany(m => m.AssemblyReferences)
Now I noticed that the WPFToolkit.Extended is not in the result list. I assume because it is referenced in XAML only.
Is there a better way to solve this than instantiating a dummy instance of that assembly in the code (according my experiments this will work)?
When i added the silverlight dll in the wpf application , i got the following exception.
Could not load file or assembly "System.Core, Version=2.0.5.0". The located assembly's manifest definition does not match the
assembly reference.
This is happening only in VS 2010 professional Beta 2.
You cannot use Silverlight directly in a WPF application, as they do not use the same version of the .NET Framework, thus the error message
Could you give some more details on your scenario ?
If you have a WPF app, you have more than what Silverlight can give to you.
If you are building a solution with multiple products, and one is WPF for the desktop, one is Silverlight for the Web, you need to create 2 different projects in VS.
Take a look at the source tree here:
http://expressionblend.codeplex.com/
Specifically, the Expression.Samples.Interactivity.Design branch.
This shows a few examples of how to put in property editors for use with Blend. I'm not sure if the same concept is transportable to the Cider design surface, but heck, Blend is nicer for pure XAML editing anyways. :)
I'm currently trying to customize a Visual Studio Isolated Shell so it opens a XAML file and its designer without a solution or a project. Therefore, for the designer to load, Visual Studio need to recognize every xaml tag in the XAML file or it won't load telling me that the document contains errors.
I'm currently trying to manually load an assembly from Telerik's control set (RadControls) without a reference since I need to use the designer without a solution/project.
Is it possible to manually load an assembly in XAML from a "custom" .dll like Telerik's without a VS project reference so the custom controls from the assembly are recognized by Visual Studio at design time (in order to use the WPF designer)?
Thanks!
SatixX
maybe you can read the namespace references out and try to resolve the assemblies in GAC and/or any other location (think of standard paths .NET itselfs looks for assemblies). Then try to load them with reflection. Afterwards you then could try to load the XAML. But: if an assembly isn't found, you should throw an error and stop loading the XAML. Also, considering an appdomain might be well suited because you can unload it again.
-sa
I have resources in separate assemblies to be used by multiple WPF apps and this is working fine. Now I am creating a Silverlight 3 app and am trying to use the same assembly to get the same resources. I get an error at the time of adding a reference, saying only Silverlight assemblies can be referenced.
What's the best way for me to do this? Must I have 2 separate sets of assemblies for resources - one for WPF and one for Silverlight? I would not like to maintain two distinct but identical resource assemblies...
Thanks
Note: "link-adding" a file resolved the issue of sharing the same xaml across multiple assemblies. However, to me, one major drawback is that this feature is not supported in Blend 3! Blend keeps trying to find the file locally in the project tree.
Unfortunately, .NET assemblies cannot be referenced from a Silverlight app.
For details and possible solutions, see http://www.pagebrooks.com/archive/2008/10/11/sharing-code-between-.net-and-silverlight-platforms.aspx.
Can you store the resources externally and then use a pre-build step to copy the files into a silverlight assembly that you reference in your project? That was you can avoid having duplicate assemblies and just change the resources in a single location.
I used the shader templates given through Greg Schechter's blog: http://blogs.msdn.com/greg_schechter/archive/2008/08/11/a-visualstudio-buildtask-and-project-and-item-templates-for-writing-shadereffects.aspx
It was all simple to add the wpf shader templates and create the project. I'm also able to see that the shader is working through the visual studio 2008 designer when editing my xaml. But I get this error when I run my program:
Cannot find type 'ShaderEffectLibrary1.Effect1'. The assembly used when compiling might be different than that used when loading and the type is missing.
Make sure your top level project (for the GUI) also has a reference to the ShaderEffectLibrary. I ran across a similar problem today where I was referencing a third-party library from within my WPF user control library. It built fine, but then I would receive a similar exception at execution time. It turned out that adding a reference to the third-party library from the top level project resolved the exception.