I have an application in WPF and I would do the following: In a folder I have a file .xaml that contains the screen, and a file .cs that contains the behavior of that screen. I need to generate a single .dll file from these two files (xaml an cs) and be able to access this .dll file within my application, so that this screen would make part of my application. I have no idea how to do this. Could anyone help me???
Thank's
Have you looked into Prism? It is useful for the scenario you describe, as long as you aren't trying to compile the screen at runtime. If that is what you're trying to do, I don't think you can associate a class with loose XAML.
If you have a ViewModel, and a View without code-behind, then you could potentially do this during the lifetime of the application. However, I think it will be far easier to compile these files, and have Prism load them as a module.
Related
I am trying to centralise my localisation in a multi project solution.
A decision was made to use the extension which works well in the code behind, but not in the xaml. The .resx file was working sitting in the local project properties directory
lex:ResxLocalizationProvider.DefaultAssembly="Project1"
lex:ResxLocalizationProvider.DefaultDictionary="Strings"
But I can't seem to get it to consume the propeties in a different project
for example
lex:ResxLocalizationProvider.DefaultAssembly="clr-namespace:Localisation;assembly=Localisation.Properties"
lex:ResxLocalizationProvider.DefaultDictionary="Strings"
and iterations of the same, is this possible?
As it turns out the solution was to create linked files to the other project's resx files rather than a direct reference from within the xaml bit clunky but a solution.
Has anyone had experience, or is it even possible to load an external XAML file into a WPF project from a hosted website.
We are wondering because we are defining the XAML file as our "styles". We would like a person not familiar with XAML to edit the file and then we don't have to redeploy the whole application, but next time the application loads it will just reference the changed XAML file.
Or is this not possible because the XAML files are compiled into the project?
Or would an option be to load an external XML file in code behind and populate our "style" properties that way? Is this possible?
We currently are using ResourceDictionary and calling an internal XAML file in the application, but we would like a more dynamic solution.
Using XamlReader.Load you can use the XAML parser. There is a performance hit from parsing XAML instead of BAML, and downloading a file from the network could negatively impact the (in my experience) often already slow startup times for WPF applications. The blog entry below provides a nice explanation of dynamically loading resource dictionaries.
http://blogs.interknowlogy.com/2011/09/02/xamlreader-looseresourcedictionaryfiles-parsercontext/
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.
In WPF applications all the views are inherited from System.Windows.Window and have an associated xaml and codebehind file. That seems logical.
However I'm confused that why does the App file, inherited from System.Windows.Application, have a xaml file? Although it is an application and not a view (It is not visible)? I know that this file is usually used to define application resources, etc, and xaml provides an efficient way of defining them. But that can also be done programatically. Then what benefit did the designers of wpf achieve by having both the xaml and code behind files for "App"? Wouldn't one of them have been enough?
However I'm confused that why does the App file, inherited from System.Windows.Application, have a xaml file? Although it is an application and not a view (It is not visible)?
Remember that XAML is not a UI language, but a general declarative language. While it's true that it's mostly used to represent UI for WPF or SilverLigth, it's also used to declare graph of objects in other non-UI technology.
The first example that comes into my mind is the Workflow (the XOML is a derivate of the XAML), SharePoint also use XAML in some hidden parts, and I've seen in a customer project with use XAML as a meta-language for generating web-apps (and yes, it actually outputs HTML).
Then, to answer to your question, the application have both files (and it is not actually a requirement) because you can :
declare some objects (in the xaml)
override the behavior of the application (by overriding appropriate methods)
Designers can specify resources for entire application without entering any code and use it in any Window. Its something like a root for all windows. For example, if you use one style for every TextBox (or any other control) in every window, you can specify it in App.xaml and bind anywhere without duplicating.
I am trying to merge all the assemblies of an class library in a single .dll file.
I can merge all the assemblies using the Ilmerge but is that when I use the merged dll in a Silverlight application I am having trouble when a template is apply to my control and binding problems if I use a control that inherits with UserControl.
is there any solution to solve this problem?
The problem is that when the initial dlls are built the Xaml in the project is added as a resource in the dll. The code generated to load this xaml will look something like this:-
System.Windows.Application.LoadComponent(this, new System.Uri("/SilverlightLibrary1;component/MyControl.xaml", System.UriKind.Relative));
Note how the name of the dll forms part of the Uri need to fetch the xaml. I doubt IlMerge is able to spot that and fix it up. Hence once merged the Uris cannot be found.
A resolution for this is probably uglier than multiple references or simply creating another project that links all the code files involved.