I found source of WPF.MDI and I try to use it in my project without any specific dlls. So, I added source into the project
Then, wrote xmlns declaration xmlns:mdi="clr-namespace:WPF.MDI" and created a container with MdiChild
<mdi:MdiContainer Theme="Aero">
<mdi:MdiChild />
</mdi:MdiContainer>
But, I received an error XamlParseException.
I guess, I do it wrong at all. But, there is any solutions for this?
UPDATE:
When I put WPF.MDI.dll into folder with .exe file and start it - there is no errors. Why it wants to find dll?
Try setting your namespace declaration like this:
xmlns:mdi="clr-namespace:WPF.MDI;assembly=MDISource"
So add the assembly part.
You need to add this if your class is in a different assembly. See MSDN:
assembly= The assembly that contains some or all of the referenced CLR
namespace. This value is typically just the name of the assembly, not
the path, and does not include the extension (such as .dll or .exe).
The path to that assembly must be established as a project reference
in the project file that contains the XAML you are trying to map. In
order to incorporate versioning and strong-name signing, the assembly
value can be a string as defined by AssemblyName, rather than the
simple string name.
assembly can be omitted if the clr-namespace referenced is being defined within the same assembly as the application code that is referencing the custom classes. Or, an equivalent syntax for this case is to specify assembly=, with no string token following the equals sign.
UPDATE
Read this answer.
The problem was solved after deleting the strings 96-100 in MdiContainer.cs
if (Environment.OSVersion.Version.Major == 5)
ThemeValueChanged(this, new DependencyPropertyChangedEventArgs(ThemeProperty, Theme, ThemeType.Luna));
else
ThemeValueChanged(this, new DependencyPropertyChangedEventArgs(ThemeProperty, Theme, ThemeType.Aero));
Related
When I run my WCF service, I get the error
"Could not load type
'CompanyName.Services.WCF.GenericNotes.Entities.GenericNote' from
assembly 'CompanyName.Services.WCF.GenericNotes,
Version=1.2.0.7,Culture=neutral,PublicKeyToken=null'.
True enough, the GenericNote type is not in CompanyName.Services.WCF.GenericNotes, but it is in the CompanyName.Services.WCF.GenericNotes.ENTITIES assembly, the dll for which is included in my program's directory. I determined that this type is needed by a client I'm instantiating by looking at the client's definition from metadata, so I cannot touch the file that actually looks for the type. The proper 'using' directives were provided there. How come .NET is looking for the type in the wrong assembly even though the full name is provided? How does it determine where to look for a type?
This scenario usually happens for one of two reasons:
there is an incorrect assembly specified (as text) in a config file - check the config files that your application is using
a type has been moved between assemblies; meaning: when SomeAssembly.dll was compiled, the type was in CompanyName.Services.WCF.GenericNotes.dll, but it has since moved to CompanyName.Services.WCF.GenericNotes.Entities.dll and you SomeAssembly.dll has not been rebuilt with that dependency; for this, there are two options:
rebuild SomeAssembly.dll with the updated dependencies, or
add [TypeForwardedTo(typeof(CompanyName.Services.WCF.GenericNotes.Entities.GenericNote))] to 'CompanyName.Services.WCF.GenericNotes.dll and rebuild it (note that this requires a dependency to the project that now has the type); this attribute is used by the runtime to resolve types that have moved (note that there is also [TypeForwardedFrom(...)] in some frameworks, which works similarly but with different directionality)
I have a current assembly in my application and I would like to add a class from external cs file into this assembly. Is it possible to do it? I would like to use it like plug-ins. Now I'm trying use:
System.Reflection.Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly();
and Activator,but without success. My application is using Roslyn, so maybe it can do it.
Any idea will be appreciated.
Edit: Next problem with it is: Can I use external file (cs file with class) to get instance from this file but the constructor of class needs reference to sceneManager from current assembley. So is possible to send a reference to Roslyn of something like that and get instance of class from it?
You cannot modify an existing assembly that has already been loaded.
Instead, you can compile code to a new assembly (using Roslyn, CodeDOM, Sigil, or similar libraries) and load that assembly using reflection.
A '.cs' file by itself is just text. You can't do anything with it without compiling it through some route. But no: you can't add extra classes into an assembly at runtime. You can compile the code at runtime via CSharpCodeProvider or similar, and load the generated assembly. It is a lot of messing, though. Depending on the context, tools like Iron Python may be preferable, if you need to do a lot of things from scripts at runtime.
I see in the CSharpInteractive.rsp you can add a reference to a DLL in the GAC using /r:
How do you add references to your own DLLs?
I tried System.Reflection.Assembly.LoadFrom, it didn't fail but didn't work.
I am trying to add a reference to my DLL that has extension methods.
If I try to add the code for the extension method directly in the interactive window I get this error:
error CS1109: Extension methods must be defined in a top level static class; XYZ is a nested class
You should be able to specify a full path for the assembly, in the same way as the gac assembly.
Normally you don't need to change the rsp though. You can add references in a regular submission using:
#r "path"
Disclaimer: I work at Microsoft on the Roslyn team.
I see that my application has the wrong name.
When I go to:
Project -> Application properties...
I see an Assembly name and a default namespace.
Is it safe to just change these two to the values which would better represent my app or will it break something?
Its probably fine to change those two settings:
Assembly name is the name of the output assembly (without the extension)
Default namespace is the name of the namespace that Visual Studio uses when adding new code files.
As long as you don't have some code that depends on the assembly having a certain name you should be fine.
Yes, it is safe. Assembly name is your .exe or .dll file name. Default Namespace, in C#, is the default namespace inserte in top of your files when you create a new file. In VB.NET the "default namespace" means something different (it is prepended to every namespace you define in your project)
Yes, the default namespace is always safe to change. This will just affect what namespace Visual Studio will use when you create a new file in your project. It will not affect existing types; you will have to change those manually.
Assembly name is likewise safe to change.
However, if you have built other software against this assembly or distributed the assembly to others then changing the namespaces of types or the assembly name is a breaking change, and will cause those applications or assemblies to fail if used with a new version of your assembly.
You can certainly change them, but changing them will have consequences. Changing the assembly name simply changes the name of the output DLL or EXE file. The contents are basically unchanged, but anything that references your assembly will need to update the reference.
Changing the root namespace is a little more annoying, but it is also allowed. You will likely end up having to go through a lot of files and fix namespace references, and like renaming the assembly, anything that references your assembly will need to be updated.
From an API perspective, both of these are 'breaking' changes due to the required changes to anyone who references your assembly.
If it is a ClickOnce Application, you will have issues in autoupdate for existing installations.
My application references another a project which has an XSD file in it.
Whats the best way to get that XSD?
I did a bit of googling and found suggestions like load the assembly and get it from that, is there no easier way?
If the XSD is an embedded resource in the assembly, then you need to get it from the assembly.
If your project references and uses the assembly, then you won't need to load it again (you don't need 2 copies in memory).
The easiest way to get to the assembly, would be from one of the types defined in it:
Type t = typeof(TypeInOtherAssembly);
Assembly assembly = t.Assembly;
assembly.GetManifestResourceStream(...);
If you've added the XSD as a resource then the easiest way is to make the auto-generated Properties.Resources class publicly visible and reference the auto-generated property. You could also keep Properties.Resources internal and add an InternalsVisibleTo attribute to allow your other assembly to have access.
Other than that approach, you can use the GetManifestResourceStream on the target assembly to extract the XSD information.