C# 2.0 code consuming assemblies compiled with C# 3.0

.net-3.5cnet

This should be fine seeing as the CLR hasn't actually changed?

The boxes running the C# 2.0 code have had .NET 3.5 rolled out.

The background is that we have a windows service (.NET 2.0 exe built with VS2005, deployed to ~150 servers) that dynamically loads assemblies (almost like plug-ins) to complete various work items asked of it. Whenever we roll out a new version of the bus logic, we just drop the assemblies on an FTP server and the windows service knows how to check for, grab and store the latest versions. New assemblies are now built using VS2008 and targetting .NET 2.0, we know that works ok. However we'd like to start taking advantage of C# 3.0 language features such as LINQ and targetting the assemblies against .NET 3.5 without having to build and deploy a new version of the windows service.

Best Answer

C#3 and .Net 3.5 adds new assemblies, but the IL is unchanged.

This means that with .Net 2 assemblies you can compile and use C#3, as long as you don't use Linq or anything else that references System.Linq or System.Core

yield, var, lambda syntax, anon types and initialisers are all compiler cleverness. The IL they produce is cross-compatible.

If you can reference the new assemblies for 3.5 it should all just work.

There is no new version of ASP.Net - it should still be 2.0.50727 - but you should still compile for 3.5

Related Solutions

C# – Could not establish trust relationship for SSL/TLS secure channel — SOAP

The following snippets will fix the case where there is something wrong with the SSL certificate on the server you are calling. For example, it may be self-signed or the host name between the certificate and the server may not match.

This is dangerous if you are calling a server outside of your direct control, since you can no longer be as sure that you are talking to the server you think you're connected to. However, if you are dealing with internal servers and getting a "correct" certificate is not practical, use the following to tell the web service to ignore the certificate problems and bravely soldier on.

The first two use lambda expressions, the third uses regular code. The first accepts any certificate. The last two at least check that the host name in the certificate is the one you expect.
... hope you find it helpful

//Trust all certificates
System.Net.ServicePointManager.ServerCertificateValidationCallback =
    ((sender, certificate, chain, sslPolicyErrors) => true);

// trust sender
System.Net.ServicePointManager.ServerCertificateValidationCallback
                = ((sender, cert, chain, errors) => cert.Subject.Contains("YourServerName"));

// validate cert by calling a function
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);

// callback used to validate the certificate in an SSL conversation
private static bool ValidateRemoteCertificate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors policyErrors)
{
    bool result = cert.Subject.Contains("YourServerName");
    return result;
}

.net – Does the .NET 3.0 SP1 installer also install .NET 2.0 and 3.0

You should just install .NET 3.5 SP1, and you'll get .NET 2.0 SP1 and SP2, as well as .NET 3.0 SP1 and SP2.

Best Answer

Related Solutions

C# – Could not establish trust relationship for SSL/TLS secure channel — SOAP

.net – Does the .NET 3.0 SP1 installer also install .NET 2.0 and 3.0

Related Topic