Develop Reference

How can I use .NET 4.7 assembly in .NET 2 project?

I want to reference an assembly which is written in .NET 4.7 in a .NET 2.0 project in Visual Studio. I'm aware of a former practical solution to my question (here) but honestly I didn't quite understand that (I even read the solution in CodeProject). I even exported the assembly as COM (using tlbexp.exe), whenever I want to import that (using tlbimp.exe) or add a reference to, I got an error saying that I cannot use an assembly which is exported from a .NET assembly. Could someone please guide me through it from the first place? When I come to COM programming, I'm almost lost.

The only way I can see is you take the assembly compiled against .NET 4.7 and with COM-visible types and host it into a separate host .exe (thus making an out-of-process COM server). You'll need to read-up on this on how to create an OoP COM Server in .NET.
Your .NET 2 client .exe can then refer to the COM types registered by the host. As far as .NET is concerned it is talking to COM. The fact that it is .NET 4.7 under the hood is incidental.
You will end up with two processes talking to each other over a COM "wire". COM is a binary protocol and is language independent.
I even exported the assembly as COM (using tlbexp.exe), whenever I want to import that (using tlbimp.exe) or add a reference to, I got an error saying that I cannot use an assembly which is exported from a .NET assembly.
You would not have been able to to this because you are mixing a .NET 2 process with 4.7 types (in-process COM). That's why we went out-of-process.
Remember, your .NET client will have to add a COM-reference and not a .NET assembly reference. Treat everything as COM and it could work.
Note:
As per TheGeneral's point below, you may need to ensure that the .NET 2 CLR is installed on the client machine as well as .NET 4.7

How To Create A VB Backward Compatible ActiveX COM DLL (w/ DllRegisterServer Entry Point) In C#

I did look at the following question, however, it doesn't resolve my issue.
- Unable to register DLL using Regsv32 - error "Dll was loaded but the entry-point DllRegisterServer was not found"
Unable to register DLL using Regsv32 - error "Dll was loaded but the entry-point DllRegisterServer was not found"
The problem I am facing is that a new DLL created w/ C# has to literally work within a legacy POS system running in Windows XP .NET 4.0 that was originally created with Visual Basic 6.0, which automatically created all of the proper entry-points (such as DLLRegisterServer) within the DLL assembly. However, these ActiveX COM entries, since they are no longer used, are not created with C# in Visual Studio 2012/2013. So, my question is, How can I create a Windows XP .NET 4.0 (VB backward compatible) ActiveX COM DLL with C# in Visual Studio 2012/2013, to replace the original VB DLL ? Can these entries be entered manually (& successfully compiled) in the C# DLL (i.e., using ???.??? STDAPI DllRegisterServer(void) { return true; }) ?

Your terminology is a little confusing: there is no such thing as "Windows XP .NET 4.0", but it sounds like you want to use .NET 4.0 on Windows XP. That would be OK. Note that your POS must be running Windows XP SP3. Note that .NET 4.5 and above are not supported in Windows XP. Your new DLLs must be compiled under .NET 4.0 or earlier. There are special complications if your POS software already uses .NET for anything else. I'll assume here that you are using .NET 4.0 and that the POS doesn't otherwise depend on .NET.
You do need to install on the POS machines an appropriate version of the .NET runtime (the version under which your DLL has been compiled is the best choice). But after that - yes, of course RegAsm will allow you to register a COM DLL (not RegSvr32 however; RegSvr32 doesn't know how to register a .NET DLL). As I mentioned in a my previous comment, the details in the registry will necessarily be different from the details for the VB6 DLL.
The installers for the different supported .NET runtimes are available from Microsoft. There are two options:
The ".NET 4.0 Client Profile installer" is currently available here:
http://www.microsoft.com/en-us/download/details.aspx?id=24872
The "Full .NET installer" is currently available here:
http://www.microsoft.com/en-us/download/details.aspx?id=17718
If you can help it, you want to compile your DLL using the ".NET 4.0 Client Profile" option, which is a subset of the whole runtime with only the most commonly used features. The Client Profile is significantly smaller. You will know immediately if your application is compatible with the Client Profile simply by trying to compile it with that option. If you are using something that is not included in the Client Profile, your DLL will fail to compile. In that case, try first to see if you can accomplish the same functionality without using the non-client-profile feature. If you can't, then use the full runtime.
Now the hard part: you don't specify if your DLL exposes a bunch of custom interfaces, whether it only consumes interfaces declared by the application, or a combination of both. You also don't specify how the POS software knows about your DLL and whether it uses Automation (IDispatch) like VBScript would or "custom" interfaces, and you don't say who declares the interfaces. Setting up the appropriate interfaces in C#/VB.NET can be a tricky problem because VB6 doesn't exactly make it easy to look at the details.
You can pull the most critical information from the existing DLL by registering it and looking at the resulting classes via the "OLE View" tool. The rest of the details will depend on how the main POS application uses your DLL. The full details of what to do can be complex and are well outside of the scope of any one single answer in Stack Overflow.

So basically you are trying to create dotnet based COM component. Set your project property as COM visible and Register your assembly using Regasm
regasm myDotnetCOM.dll
OR
regasm /codebase myDotnetCOM.dll
Now you can use CreateObject for this COM component.

Call .NET 4.0 WPF Class Library From .NET 2.0 Application

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.

Creating a Single DLL for Silverlight and Non-Silverlight

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.

Sharing C# code between Windows and Silverlight class libraries

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.