I've got a Problem. I need to use some classes from another Library DLL, that has been written a year ago, in my WPF Project. Therefore I reference this Library in my Project. But when I want to rebuild my solution I always get some warnings that my assembly cannot be resolved because it uses some dependencys that do not match my targeted framework.
This is one of the Errors
The referenced assembly "istis.AcademyOne.ClassLibrary, Version=2.1.0.1, Culture=neutral, PublicKeyToken=fd9f6afaca722199, processorArchitecture=MSIL" could not be resolved because it has a dependency on "System.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client". Please remove references to assemblies not in the targeted framework or consider retargeting your project. A1RevisionControls
Does anyone know a workaround or a solution so I can keep the original DLL and use it in my WPF Application ?
EDIT : Ok I solved the Problem switching my Target Framework of my WPF Solution to .NET Framework 4.0 instead of Framework 4.0 Client Profile.
One method would be to put the old dll behind a WCF facade. Another option would be to include the old dll in a new project, and use some sort of inter-process communication like named pipes to talk between the two.
Or you could just share the class files with a new .Net 4 class project, and reference that new class library. This example and this example talk about doing it in Silverlight and/or WCF, but the principle is exactly the same.
Related
I have created a VS2013 solution that contains multiple projects. One of those projects is a portable class library targeting .NET 4.5+, Silverlight 5, Windows Store 8+ and Windows Phone 8 and this project contains a reference to an OData service in an accompanying web application.
The portable class library references Microsoft.Data.Services.Client.Portable (among others), added via nuget (WCF Data Services Client).
I have then added the portable class library to a WPF (.NET 4.5) application, a Windows Store application and a Windows Phone application and written some very basic test code to access the service. This works fine in Windows Store and Windows Phone.
The WPF application however will not compile. The errors are...
The type 'System.Data.Services.Client.DataServiceContext' is defined
in an assembly that is not referenced. You must add a reference to
assembly 'Microsoft.Data.Services.Client.Portable, Version=5.6.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The type 'System.Data.Services.Client.DataServiceQuery`1' is defined in an
assembly that is not referenced. You must add a reference to assembly
'Microsoft.Data.Services.Client.Portable, Version=5.6.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The thing is, I also added the WCF Data Services Client to the WPF application via nuget, but it does not add a reference to the portable library (packages\Microsoft.Data.Services.Client.5.6.0\lib\portable-net45+sl5+wp8+win8\Microsoft.Data.Services.Client.Portable.dll), instead adding a reference to the full framework 4.0 version (packages\Microsoft.Data.Services.Client.5.6.0\lib\net40\Microsoft.Data.Services.Client.dll) - which in turn is causing the error I am seeing.
Is there something I am doing wrong here or is this an error in the installation package? Note that if I delete the offending reference and add the alternative reference manually then all is well so though I have a work-around I would still like to know if I am the cause of the error.
Looking at the NuGet source code this behaviour seems to be by design.
The WCF Data Services Client contains assemblies for the following frameworks:
.NET Framework, v4.0
.NET Portable, net45, sl5, wp8, win8
Silverlight, v4.0
Installing this NuGet package into a project that targets .NET 4.5 will result in the .NET 4.0 assembly from the NuGet package being referenced. NuGet considers the more specific .NET framework to be a better match for your WPF project which targets .NET 4.5.
There is a comment in the NuGet source code about this when it looks for the best matching assembly in the NuGet package.
// Let's say a package has two framework folders: 'net40' and 'portable-net45+wp8'.
// The package is installed into a net45 project. We want to pick the 'net40' folder, even though
// the 'net45' in portable folder has a matching version with the project's framework.
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 am building a Silverlight app. As I have classes to be consumed by Silverlight and .NET modules, I have created a Silverlight project with all the classes in it and then, a .NET project linking('Add Link') to the classes in Silverlight project. This way, I have one class file compiled separately as Silverlight and .NET assemblies. I want to replicate the same for web service references. Meaning, I have web references in the Silverlight project. I am trying to 'Add Link' to reference.cs from Silverlight project into the .NET project. When I compile the .NET project, the ChannelBase class doesn't get resolved it seems due to disparity in definition of the class in Silverlight and .NET framework libraries. This results in compilation error stating unresolved ChannelBase. Sounds like a dead end to me. Do you see a way around this problem?
I'm afraid this is not possible. Both proxies are completely different: one of them is synchronous while the other one is not.
The best thing you can do is to share the service defined classes, not the whole proxy. Just create those classes beforehand, use "Add as link" to reuse them in both projects, and then when you add the service reference, mark the option "Reuse types in referenced assemblies".
Just in case someone else stumbles on this. I had a similar problem. I was generating the proxy using slsvcutil.exe and trying to compile it for .net and monotouch. I kept getting ChannelBase not found. Which made no sense at all. Finally I commented out the CookieContainer property in the proxy client class and low and behold the compile error went away and the proxy works for monotouch.
I created my first Silverlight application. In the client project, I want to define a Dataset object. To do so, I figured I first need to reference the System.Data namespace in the dll of the same name.
When I add a reference to the dll, I get a msg that "it was successfully added," I see thje dll in copied to the bin folder, and then it promptly removes the referenced dll from the bin folder.
Why?
There is no Dataset class in the Silverlight SDK in fact there is no System.Data namespace for Silverlight.
Silverlight only has access to fraction of the features you would find in the full .NET framework. Certainly many of these older concepts such as the DataSet whilst still useful in some places are now being replaced with new approaches such as Entity Framework.
You should consider looking in to WCF RIA Services if you want to do some serious data work with Silverlight.
I have Silverlight application using NHibernate as a ORM. I have projects for Data(mapp and entities), data access and Silverlight. I want to add to SL project reference to data access to execute methods, but SL can only get reference from other SL project.
How can I omit it? If I host data access project on WCF I could reference WCF to SL?
Please help ! :)
Yes, you can expose your data access assembly as a bunch of WCF services and then call them from the SL application.
There is also another way - make a Silverlight class library, and then add new linked files to it - those linked files being the class files from your data access assembly.
Here is a previous answer that explains the linking, although you should note that because your data access classes will now being using the Silverlight runtime you may not have access to all the System namespaces that you want (although you can pick and choose what files you want to add to the new project, and refactor the ones that don't work because of this).