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.
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 have a silverlight 4 project that uses wcf ria services to connect to the server. I have a public class that I need to use on both the client (silverlight) and server. What is the best way to accomplish this?
I have tried using the .shared.cs file convention on the server as well as a linked file (original is on the server). The client thought there was a duplicate class so I changed it to a partial class (I would prefer not to). Then it complained about duplicate properties so I tried the solution to this stack overflow question. The problem I run into using this solution is not being able to access my enumerations that are in the original class on the server.
I also tried a creating a class library project that both of the other projects could reference (silverlight client and server). The problem is finding a type of project to create that both of the projects can reference. Silverlight complains about non silverlight projects and vice versa.
Have you considered using the Portable Library Extension tools.
To quote from here, the Portable Class Library project enables you to write and build managed assemblies that work on more than one .NET Framework platform.
I think the best solution here would be to create a new project in a solution (you may call it Helpers, Common, etc) and add a reference in both client and server projects. That way you will use the same class in both of them and if you change the structure of a class it will affect both projects.
I'm not sure about where your problem came from (what do you mean by not being able to access your enumerations ?) however you may find useful to know that .NET supports a feature called assembly sharing that is meant to share some basic type across silverlight and .net. Just keep in mind that you should reference the Silverlight assembly, not the silverlight project. If this break your compilation order, add also a "fake" project reference into your csproj file like this:
<ProjectReference Include="..\MySilverlightSharedProject.csproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
as documented here
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.
i'm building a Service-Client application using Silverlight and WCF, i have a Model project (which contains POCOs) on the Server side, and i wanted to share those same entities to the Silverlight-Client Application, and i thought, hey! I can change the Model project to be a Silverlight class library, and it should work just fine.
I did the change and now, i'm able to add the references however it is getting the exclamation mark like when the reference is not resolved... and if you take a look at the properties the value of "Resolved" is set to "False", this is causing the following Code Analysis Errors:
CA0058
[CA0001][2]
Please note:
this is not the typical question about referencing a Typical Class Library from a Silverlight project (i Know that can't be done), but the other way arround.
It should work fine (unlike what Wayne says, you can actually reference Silverlight assemblies from projects that target the full .NET Framework). However, you may have references in this project that the full .NET Framework can't load (you generally need to keep your references to the most base types). You've got two alternative options.
Create two class library projects (one targeting Silverlight, the other the .NET Framework), and share the files between them, as I discuss in this article: http://www.silverlightshow.net/items/Building-a-Silverlight-Line-Of-Business-Application-Part-3.aspx
Try out the Portable Library Tools (currently in beta): http://blogs.msdn.com/b/sburke/archive/2011/01/23/3-screen-coding-is-here-portable-library-tools-allow-you-to-target-multiple-net-platforms-with-one-binary.aspx
Hope this helps...
Chris Anderson
For the same reason you can't reference a CLR assembly from a Silverlight project, you can't reference a Silverlight assembly from a CLR project -- they're different runtimes.
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.