When looking at the documentation for WPF (e.g. for Selector.SelectedItem), I noticed that there are two XML naspaces: http://schemas.microsoft.com/winfx/2006/xaml/presentation and http://schemas.microsoft.com/netfx/2007/xaml/presentation.
What's the difference between the two, if any? Why are there two different namespaces that seem to point to the same group of .Net namespaces (do they really?)?
(guessing the answer)
the first version of WPF was called WinFX and was probably a separated project in MS organisation.
When WinFX joined the .Net Framework, MS has probably wished to keep the namespaces defines earlier for compatibility with existing work.
Later, new classes have been added, and MS decided to use a properly named namespace (NetFX is .Net Framework).
Related
Consider the following scenario:
A NuGet package contains two versions of an assembly, one for .NET 3.5 (in lib/net35) and one for .NET 4.0 (in lib/net40). Both are named SomeInterfaces.dll and have version 1.0.0.0, but the strong names for the two assemblies have different publicKeyToken values.
An application named CoolProgram.exe exists, and exposes extensibility features (e.g. via MEF)
Company A develops an extension AExtension.dll and references the .NET 3.5 version of SomeInterfaces.dll.
Company B develops an extension BExtension.dll and references the .NET 4.0 version of SomeInterfaces.dll.
One of the following is provided:
The extensions AExtension.dll and BExtension.dll are placed in the same folder as CoolProgram.exe, and the two copies of SomeInterfaces.dll are placed in the GAC.
The application adds the paths where extensions are installed to the CLR binding path. For example, AExtension.dll and SomeInterfaces.dll (.NET 3.5) could be placed in the directory extensions/A, and BExtension.dll and SomeInterfaces.dll could be placed in the directory extensions/B; both of these two directories are placed in the binding path of the application CoolProgram.exe.
Questions:
In situation 5.1:
Will CoolProgram.exe be able to load AExtension.dll and BExtension.dll without any problems due to them referencing two assemblies that only differ by their publicKeyToken?
Does the order in which the extensions are loaded make a difference?
Does the answer change if CoolProgram.exe does not have a strong name, but both AExtension.dll and BExtension.dll do have strong names?
The same as question 1, but applied to situation 5.2.
Optional Background Information:
If two assemblies are compatible at runtime; i.e. they expose the same public API and only differ in their implementation (e.g. one restricted to .NET 3.5 for the implementation and one using .NET 4.0 types in the private implementation code), then users will not face assembly binding problems in extensible applications even if the two assemblies have exactly the same strong name. This is not the case for situations where the public API differs in some way.
One solution to the case where the public API differs is to use separate names for each version of an assembly. This could lead to cases like the following for the ANTLR 4 Runtime:
Antlr4.Runtime.net20.dll
Antlr4.Runtime.net30.dll
Antlr4.Runtime.net35.dll
Antlr4.Runtime.net40.dll
Antlr4.Runtime.net45.dll
Antlr4.Runtime.portable_net40.dll
Antlr4.Runtime.portable_net45.dll
Antlr4.Runtime.netcore45.dll
The documentation associated with the project could be simplified if all the assemblies could be named Antlr4.Runtime.dll. In the case where users know they are working in an environment where multiple vendors could be providing code that references assemblies with different target frameworks but otherwise the same version, steps could be taken to ensure their assemblies can be located at runtime. A concrete example would be two Visual Studio extensions using ANTLR for syntax highlighting, one targeting Visual Studio 2010+ (using .NET 4.0), and one targeting Visual Studio 2012+ (using .NET 4.5). The [ProvideBindingPath] and/or [ProvideCodeBase] attribute could be used to provide exactly the functionality described in situation 5.2.
I have built up a code-first model using Entity Framework 5.
The classes have several enums.
I started out by putting the model classes in a prototype ASP.NET MVC project.
I also added the
Database.SetInitializer(new DropCreateDatabaseAlways<dbType>());
command to the global.asax.cs file.
Running the MVC application in Visual Studio produced exactly the database schema I wanted in SQL Server (2008 R2). (with int value columns for the enums)
I then copied the model code to the solution where it will actually be used, which is split into several projects, one which has the EF code, another is the ASP.NET MVC part.
I also added the same Initializer to global.asax.cs
Now when I run the project, I do get the correct tables in the database, but for some strange reason, the enum columns are missing from the tables!
How do I make EF produce the enum columns?
Enum support is dependent on .NET 4.5 so it will only work when the project targets .NET 4.5.
I'm currently working on an Xbox360 game. In this game I have lots of data stored in XML. Deserializing it through IntermediateSerializer in the XNA Game project is no problem, works like a charm. But since these structures stored in XML can be quite complicated I decided to make a simple editor for the stuff, so I (or maybe a less experienced user) could edit the objects visualy (animations, game stages etc) rather than having to write these data as XML. Then I would serialize it through the IntermediateSerializer and everything would be fine.
For this editor I created a WPF project, and referenced the Microsoft.Xna.Framework.Content.Pipeline.dll
Visual Studio recognizes the IntermediateSerializer class, and intellisense helpfully recommends to use the Microsoft.Xna.Framework.Content.Pipeline.Serialization.Intermediate namespace, but I keep getting the following error message:
The type or namespace name 'Pipeline' does not exist in the namespace 'Microsoft.Xna.Framework.Content' (are you missing an assembly reference?)
(I'm using XNA 4.0 and .NET 4)
Am I doing something wrong or is this just simply impossible?
Tenshiko
In your Application Properties ensure
that the Target framework is set to
.NET Framework 4.
By default a new WPF application targets the .NET Framework 4 Client Profile. The Client Profile is designed to reduce the download size of the .NET Framework for end users and excludes assemblies that are only used in development. In your case Microsoft.Xna.Framework.Content.Pipeline.dll depends on Microsoft.Build.Framework and Microsoft.Build.Utilities.v4.0 which are not available in the Client Profile.
It seems to me that you did set a target framework of your WPF application to ".NET Framework 4". It has to help.
I have a Silverlight app hosted in an Azure web role ASP project. The ASP project exposes a WCF service.
I would like to have one set of class definitions for the data types. Someone recommended making a third project (class library) and adding a reference to it from the SL and ASP. I started doing this, but the Silverlight project complained that you can only add references to Silverlight projects.
I then made a Silverlight class library and moved the data classes to it. However, I to add some .dll references, like to the Windows Azure storage client. Then the Silverlight class library tells me I can only add references to Silverlight 4-friendly .dlls, of which Windows Azure isn't one. Fantastic.
Is there something I can do to get around this, or am I stuck with a less elegant, redundant solution?
Multi-targeting is your best bet. There is an article explaining this in Visual Studio from Microsoft at:
http://msdn.microsoft.com/en-us/library/ff921092(PandP.20).aspx
Basically, you create both your Silverlight and standard .NET class libraries, each with a different name, and then include the same files into each. Usually the files are actually only in one of the class libraries and then soft linked in the second one.
The key is to ensure that the code in your files is compatible with both runtimes. If there needs to be separate implementation for some of your methods depending on the runtime then you need to separate these with pragmas (i.e. #ifdef SILVERLIGHT...).
If you're only doing data structures, however, there should be no issues as long as Silverlight supports the objects you are using.
See if using linked files as per this answer does the trick for you.
At the last PDC (can't remember which talk it was) they gave us the information that it will be possible to share assemblies between regular .Net 4 and Silverlight 4.
Unfortunately I can't find anything on this. Was this feature dropped? What options/limitations are there?
(There are similar questions on SO but they don't say if they apply to SL3 or 4.)
See Sharing Silverlight Assemblies with .NET Apps from the CLR Team Blog.
Basically if your assembly only references:-
Mscorlib
System
System.Core
System.ComponentModel.Composition
Microsoft.VisualBasic
That assembly can be shared by both frameworks with each framework using its own version of those references (that is .NET won't be attempting to load Silverlight's version of System.Core for instance).
Of course you will still need to limit your code to features of these references that are actually common across to the two frameworks.