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.
Related
I want to move a big pile of code to a separate project and use it as a framework for where it came from.. and other stuff too.
I started a new vb.net wpf project and started adding files from the old project but when they get added, the wpf and its associated vb file are treated as separate things. What I mean is that when I add a new wpf usercontrol file(or whatever), the vb file gets nested in the xaml file but when adding existing, they get added side by side.
I'm not sure whether they work or not, still a lot to add and a little bit to rewrite but I'd like to do this properly from start to finish. Is there a more appropriate way to do this? Or if not then how would i nest the vb files into the xaml files?
Apparently I need to add the files one by one by selecting the xaml one, then it automatically adds the .vb as nested.
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.
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.
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.
I need to display an image, which I've done without problems before, but today I decided to be tricky and use "add as link" instead. Well, now I get:
The file Images/hello.png is not part of the project or its 'Build Action' property is not set to 'Resource'.
Wait... its Build Action is set to Resource. I've seen a Silverlight solution that involves the usage of Merged Dictionaries to share files between Silverlight and WPF projects, but it's not clear to me that this would even apply to my WPF + Image issue.
Has anyone solved this problem before? I could make copies of all of the images, but that seems a little silly if I have a shared repository with clip art and the like.
Dave,
I've just tried to add image as a link to plain WPF application. Build action is "Resource" (don't confuse with "Embedded Resource"). I've added it to the root, and refer to it as <Image Source="/file_name.jpg"/> - all works fine.
The message you have is it compile or runtime? If it's a runtime, how do you refer to the image? Do you see it in Reflector, when you open your assembly (it should be under Resources folder)?
I have images in one assembly which I want to share into another. I've used Add as Link in my second assembly. In the project where the actual image files are located they are in a Resources\Images folder. In the project which links to those files the links are also in a Resources\Images folder. At runtime a XamlParseException claiming "cannot locate resource" is thrown.
My xaml which is referencing the image is in a UserControls folder.
In the project which actually contains the images the path ..\Resources\Images\Blah.png works fine as expected.
Opening the DLLs in Reflector makes it obvious that in the assembly with the linked images holds the images at the root level - the compiler is not respecting the folder location. So in the project with the linked files I have to use ..\Blah.png to find the resource.
Surely a bug in the compiler?