Develop Reference

Porting A .net Class Library To Windows Store Apps Class Library

I have a class library that targets .net 4 and is used across different platforms via Mono.
I now want to port it to be used by Windows 8. I know the name keeps changing but this is currently called a "Class Library (Windows Store Apps)" in VS2012.
I initially started with trying to port everything to a "Portable Class Library" but this was proving too difficult as some things simply didn't have a generic approach that would work on all platforms targeted, and other things that were supported simply weren't available to the compiler.
So I've created a Windows Store Class Library and created links to the existing files of my standard Class Library so updating once will update both. I am planning on using pre-processing directives to make changes between the two class libraries
E.G
#if NETFX_CORE
Task.Delay(someTime);
#else
new System.Threading.ManualResetEvent(false).WaitOne(sometime);
#endif
My question is if this method seems a sensible approach? I have the same default namespace and assembly name. Could this ever cause issues to my compiler? The assemblies target different platforms so would never be used together in the same application but do both sit in the same solution in Visual Studio.

Overall, yes that should work. That specific case is a poor example, because the two implementations function very differently, illustrating that you may need to rethink some aspects of your design. For cases where there is a similar API swap (with similar semantics), I personally tend to move the difference behind a helper method, so my "main" code doesn't need to worry about this - just the helper code. Reflection would be a good example of this (the changes to reflection are annoyingly deep).
The two projects with different target platforms should be fine. I occasionally hit an IDE glitch where it complains about temp files. I think this is due to sharing files between projects. I've logged it on connect

Try
Task.Delay(msDelay).Wait()

Possible to combine C#.net, VB.net and ASP.net?

I want to build a website in ASP.net, and to integrate a module which is written in C#(too complicated to rewrite in VB or ASP).
Now I just want to know whether it is possible to have a website that integrates all three?
Thank you.

Yes. You can have a WebSite integrating all three.
Just make your complicated C# a .NET library and include it in your VB.NET/ASP.NET project.

I think you only have to reference the dll's from your modules which are written in c# or VB to call your public functions. I've done this in a windows form application and it worked fine.

You may also want to consider simply learning C#. Most of what you know from VB.NET is directly usable in C#, since most work involves using framework classes and the languages share most features.
It is mostly a matter of syntactic preference, and while a new syntax may sting your eyes for a bit the learning curve will be steep and soon you will have left your old preferences behind.

You have a couple of options when integrating languages in ASP.NET. If you're creating a "web site" (as opposed to a "web application" which can use only one language) then each page can use a specified language, because essentially each page is compiled separately. Some can use VB, some can use C#. No problem.
However, what you describe sounds even simpler. You claim that there is an existing C# module which you want to use in your VB website. Is this module compiled into its own assembly? If that's the case then the language that was used to create the assembly is immaterial. Once it's compiled, it's a .NET assembly and can be referenced by any .NET language. It's no longer a matter of VB vs. C# (or any other language) once it's compiled.
If it's not a compiled assembly, but rather a bunch of class files, can it be compiled as its own assembly? That's generally good for keeping things modular. Within a single .NET solution you can have each project use different languages without problem. This module can be a library project written in C# and your site can be a web site (or web application) project written in VB, which references the library project.

Since all these assemblies ultimatly use the same CLR (hence the name Common Language Runtime), they can be used together with no problem.

referencing asp.net c# classes/methods in silverlight project

Does anyone know how to do this? I built a backend c# class in asp.net but want to access these same classes without recreating them in silverlight. Is this a possibility?

You can reuse the cs files by adding them to your project AS LINK. Right click in your project and select Add Existing...Browse to your file and in the Open Button, use the pulldown arrow on the right to select Add As Link. You will see the file added to your project with an icon that with the little Windows Shortcut icon overlayed on it.
Just remember - the ASP.Net runs on the .Net runtime. Silverlight runs on the CoreCLR (Silverlight runtime.) Not everything that compiles in oone will compile in the other...
To separate things a little bit, #if directives can help, you can also use Partial Classes and partial methods (to add content that only runs on the server or on the client.)

RIA Services is definitely the way to go for sharing code between ASP.Net and Silverlight.
As well as the previously mentioned generation of domain service models, it also lets you share individual files between the web-app and Silverlight by simply inserting "shared" in to the filenames. e.g. "MyClass.shared.cs".
RIA services does not take long to get to terms with (and there are good tutorials about). Try this one.

Well, ASP.NET itself isn't going to work (ditto many of the full libraries), but I'm assuming you just mean you local domain model etc.
IIRC you can try to simply reference it, but it may well generate a warning message. Of course you need to be exceptionally careful not to use anything that the other platform doesn't support...
IMO, the better option here is to create a second csproj that includes the same .cs files (or cheat with a wildcard/deep include). And build both. Same C#, different dll/platform.
Is isn't uncommon to find that you need a very small usage of #if directives, too.

WCF RIA Services may help you solve your problem. Silverlight does not use the same runtime as ASP.Net does and you cannot directly share assemblies containing model classes on the client and the server side. To solve that WCF RIA Services will transparently generate classes on the client side based on model classes on the server side. Obviously WCF RIA Services will also allow you to create, read, update and delete objects of these classes using a web service.
MSDN has more specific information about WCF RIA Services Client Code Generation.

Dealing with multiple versions of a single c# dll (plugin)

I have a challenge similar to creating-my-own-plug-ins-for-my-own-project-in-c# and late-loading-a-net-plugin-dll, with the added headache of being able to specify a version to use. My current idea is to simply use console apps, with folders named by version. I'd then find the folder and load the console app by known name, using Process.
I'd like to avoid having to write out and read in text, which is the only real way I can see for a console app to talk to my 'control' windows forms app. Using dlls seems like a possibility, but I haven't done much with dynamic loading before and it seems rather messy either way.
I've had a quick look at the Managed Extensibility Framework, but it's still under development, and aiming for .Net 4.0, which I might be able to look at, although I need this solution relatively quickly.
Any other ideas out there for accessing a specific version?

In the end I just used a well-known folder structure to contain different versions of console apps.
No, it's not clean, and probably not the best way to do it. However, I don't have control over the console apps/dlls, and this works without being too much to explain to the researchers I work with. They know research, C# is just a tool.

What are the advantages of loading DLLs dynamically?

Looking for the advantages of loading DLLs dynamically as opposed to letting your application load the DLLs by default.

One advantage is for supporting a plugin architecture.
Suppose for example you want to write a service that performs different types of tasks on a scheduled basis. What those tasks are doing, isn't actually relevant to your core service which is just there to kick them off at the right time. And, it's more than likely you want to add support to do other types of tasks in the future (or another developer might want to). In that scenario, by implementing a plugin approach, it allows you to drop in more (compatible by interface) dlls which can be coded independently of the core service. So, adding in support for a new task does not require a new build/deployment of the whole service. If a particular task needs to change, just that dll needs to be redeployed and then automatically picked up.
It also requires other developers to not be concerned with the service themselves, they just need to know what interface to implement so it can be picked up.

We use this architecture for our processing applications to handle differences that our different customers require. Each DLL has a similar structure and implements the same interface and entry method "Process()". We have an XML file that defines which class to load based on the customer and whether there are more methods besides process that needs to be called. Performance should not be an issue until your transaction count gets very high.

Loading Shared Objects dynamically is the mechanism for allowing plugins ad hoc to running applications. Without plugins a modular application would have to be put together at link-time or compile-time (look at the code of nginx).

Your question is about C#/.NET so in this world dynamic DLL loading requires advanced programming skills. This could compensate all the potential benefits of dynamic DLL loading. You would simply have to write a lot 'low level' code.
In C++/Win32 I often have to load a DLL dynamically when this DLL has some new API function which is not available on older operating systems. In this case I need to ensure the availability of this API at runtime. I cannot just link against this DLL because it will cause application loading errors on legacy operating systems.
As mentioned, you could also have some benefits in a plugin-based environment. In this case you would have more control on your resources if loading DLLs dynamically. Essentially COM is a good example of dynamic DLL handing.

If you only load the DLLs you need then the startuptime of the application should be faster.

Another reason to load DLL's dynamically is for robustness.
It is possible to load a DLL into what is known as an AppDomain. An Appdomain is basically a sand box container that you can put things into (Either portions of DLL's or whole EXEs) to run in isolation, but within your application.
Unless you call into a type contained within an AppDomain, it has no way to interact with your application.
So, if you have a dodgy third party DLL, or a DLL that you don't otherwise have the source code for, you can load it into an AppDomain to keep it isolated from your main application flow.
The end result is that if the third party DLL throws a wobbly, only the appdomain, and not your entire application is affected.