All of my cross-platform libraries are created with solutions that have two projects: one that builds on the Silverlight CLR and one on the regular CLR. Hence, every library I make has two DLLs: name.dll and nameSilverlight.dll.
This is, as far as I know today, the only way to do it.
However, I recently tried Mike Talbot's "Silverlight Serializer" DLL, and I could include the same DLL in a C# desktop and in a Silverlight application. It's the exact same file.
How did he do that? And how can I do that?
(I really need to do it, because I'm trying to serialize in a desktop app and deserialize in a Silverlight app, and the assemblies are not matching up because they're different.)
It may be that they are using the Portable Library CTP.
Silverlight 3 is a "lowest common denominator" and if you just use base/core classes, you can compile a DLL there and reference it directly from .NET. You cannot, without the portable library, do the converse however.
Related
I wrote a game in XNA a while ago, it just has two projects - a game, and a library. It worked fine, and now I am porting it to Monogame.
I have created a MonoGame Game project, and a Class Library, and put all of the files from my old XNA project into them. The Class Library builds with no problems or errors. However, it won't let me add a reference to it from my other (game) project.
It just says "Unable to add a reference to [MyLibrary]"
I read something about it possibly being because they target different frameworks - one targets .net and one targets ".net CORE" but I don't know if this is the case, or how to fix it.
Can anyone advise me on what I should do?
You're probably right about the framework targeting issues.
There are a few ways to deal with this, the first is to try and change you're library to a Portable Class Library. They are designed to be able to target different frameworks including the different frameworks MonoGame supports.
http://msdn.microsoft.com/en-au/library/gg597391.aspx
The downside of portable class libraries is that they only support a subset of the full .NET framework. If that's the case you'll want to try and change you're library into a Mono for Android Library project (or whatever framework you're targeting).
If you want to build for multiple target frameworks and need to minimize the amount of duplicate code in each project I think your best bet is to add the files as 'links' to each projects. It adds a bit of maintenance but allows you to edit a file in one project and have the change made across all projects.
If I were you I avoid the Portable Class Library both for the reasons that #craftworkgames specifies, and also from my own experience of developing a Windows 8 App - they just cause you hassle. While it's good from a design principle to separate your classes into a library of their own, I would just add them all to your development project (unless you're writing an API that you want the world to be able to use?)
I'm trying to use the Dynamic Data Display (D3) library for displaying graphs in a Silverlight 5 application (out-of-browser). Whenever I try to add "DynamicDataDisplay.dll" as reference, it gets removed again after I close the dialog.
I can however use the reference in a normal Windows Forms or WPF project. So is this some restriction with the Silverlight framework?
What can I do about this? Maybe compile D3 myself in a different way?
Silverlight applications can only use assemblies compiled by Silverlight projects. There are exceptions but for anything UI related it's always true.
As a result, if you want to use a third-party library in your Silverlight application, it needs to have a special Silverlight version to use instead of the normal version. The "normal" version is sometimes called the .NET4 version or the WPF version to contrast it with the Silverlight version.
The net effect is that Silverlight is for all practical purposes not binary compatible with the full CLR. But there is a considerable amount of source compatibility including large sections of the core framework and a partially incompatible subset of WPF.
In fact the standard approach to building parallel WPF and Silverlight assemblies is to use two projects that link all the same source files with some conditional compilation.
Luckily for you, as #dtb pointed out, Dynamic Data Display already supports a Silverlight download. But the same applies to any third-party library you might consider using: it needs to come in a Silverlight flavor.
If the D3 dll depends on the full install of .Net and not just the silverlight subset, Silverlight will not allow a direct import. You would have to host the .dll on your server and expose asynchronous service methods to it. Unless this is a really killer DLL, it is not worth it...
You can also use portable class libraries as well I'm silverlight
I have an application written in .NET 4.0 that i compile into a DLL file. I want to be able to use this DLL file in a Windows Forms .NET 2.0 application. I don't need the application to really interact much, except just passing a couple string values to the 4.0 DLL. The DLL is pretty much a bunch of Windows which i converted to UserControls and i just need to be able to reference them to display the UserControls from the 2.0 application without having to use a different exe and having to package them separately. What is the best way to do this? Because when i try to add the reference to the DLL to the 2.0 application, it gives me and error saying the DLL is built in a newer version of .NET so i can't do it that way. Is this where a COM object would come in? Any information and links i would really appreciate, thanks.
If the application can really and truly be called from a 2.0 application then the best approach is to compile it as a 2.0 application. Visual Studio 2010 (and 2008) support the notion of multi-targetted solutions. That is you can use it to compile a project for various versions of the CLR.
I would take the approach of compiling my application twice
Once for 4.0
Once for 2.0
This way you can use the DLL directly in your 2.0 application. No messy COM tricks needed
Calling a .ne 4.0 from a .net 2.0 is indeed possible. The problem is not that, but i dont think you can send the usercontrols across!
Im doing this in a couple of soultions where im passing simple classes from 4.0 to my 2.0 assemblies. The trick is to register the 4.0 assembly as a ServicedComponent (COM+), then share an interface (.net 20) betwewen these assemblies. Then in your .net 2.0 assembly instantiate the ServicedComponent and retrieve an instance of your interface from the "middleware" assembly.
As stated, you can only transfer interfaces through this, and marshalling a complex type as a UserControl i think will be very difficult.
The setting:
I got a silverlight application and a webservice both want to use the same code.
Here my problem:
If make an normal dll the silverlight
Application say's it can not
reference it.
If I make an Silverlight dll the
Webservice can not reference it.
I don't like duplicate code how can I share code between my Silverlight app and my webservice?
There are several approaches you can take to avoid duplication.
The most fundemental approach would be to use two different projects one targeting the .NET Framework, the other targeting Silverlight. Thus their references point at the appropriate set of assemblies and the Silverlight project defines the #SILVERLIGHT conditional compilation symbol. However they share the same set of code files, that is one will be using linked files. You would toggle around parts the need to be done differently using conditional compilation.
WCF RIA Services also offers a mechanism where you place code in *.shared.cs files in the server side project that will be automatically duplicated into a "Generated_Code" folder in the client side project.
There is a way to share a single set of code and a single output dll between both Silverlight 4 and .NET 4.0. However you will need to limit the references to a very narrow set of files. See Sharing Silverlight Assemblies with .NET Apps
Make two dll projects, one silverlight dll and one normal dll. Have them both reference a third project with the common code which produces a static lib. Having common code as a static lib is good anyway, since you can link it in with any sort of project.
We wrote a small Windows class library that implements extension methods for some standard types (strings initially). I placed this in a library so that any of our projects would be able to make use of it by simply referencing it and adding using XXX.Extensions.
A problem came up when we wanted to use some of these methods in Silverlight. Although all the code was compatible, a Windows library can't be referenced in Silverlight so we created a Silverlight library that had links to the same class files and put compiler directives into the classes to allow different using declarations and namespaces. This worked fine until today when I added a new class to the Windows extensions library and realised that I would have to remember to link the class into the Silverlight library too.
This isn't ideal and I wondered if anyone might have ideas for a better way of sharing extension methods and other helper code between Windows and Silverlight projects.
You cannot set a reference from a Silverlight assembly to a regular .NET assembly but you can do so the other way round.
So create a shared Silverlight assembly and add your code to that assembly. Now you can set a reference fro both your regular .NET and you other Silverlight assembly to the shared Silverlight assembly.
The restriction is that you can only put code in there that would work on both the .NET and Silverlight CLR but that is no different from sharing code.
Since this question has been answered, there is a new solution from Microsoft, Portable Class Libraries. Here is the blog post where they announced it.
I'm just about to start playing round with them for sharing code between silverlight and some server side code I'm writing, so can't add too much past the links at the moment.
Silverlight runtime is different from the normal .NET runtime. So you need to do tricks at the project level to share code between multiple platforms.
Here's how I've done this for Autofac IoC container.
With this approach you do not have to create different projects for each platform being targeted.
PS: there is also a Project Linker tool from the Composite WPF that allows to link Silverlight and WPF projects (creates multiple projects). But it does look messy.
there is a similar problem with XNA projects. Since you can target several different platforms, you're required to have different projects. The reason for this is because the base class libraries that the project references are platform specific, so you can't have just one project.
If you're curious, you can get a bit of insight from this blog:
To recompile the source for another
platform, you need another project.
The reason for this is because the
projects need to reference different
assemblies for both the XNA Framework
and the underlying .NET Framework
(Xbox 360 and Zune use the .NET
Compact Framework), and C# projects
don't provide support for referencing
different assemblies for different
platforms.
Try this http://buildassilverlight.codeplex.com/
I had some dependency issues when referencing to a Silveright class library in .Net.
An alternative way when using Visual Studio 2010 and WCF RIA 1.0:
Create a normal .Net library assembly.
Create a Silverlight class library. In the configuration of the assembly specifiy the first .NET library as the "WCF RIA Service link"
Put your code in the .NET library as "ClassName.shared.cs" files.
WCF RIA will handle copying the file to the Silverlight assembly.