I'm on a team that's currently building a MOSS 2007 based application (which relies on .NET 2), and we'd like to leverage the Entity Framework v4 (which relies on .NET 4).
Is this possible?
No. The 4.0 version of .NET has a new CLR (4.0) etc., but SharePoint 2007 is only supported on CLR 2.0.
Even SP2010 does not support .net 4.0 (yet).
Although I haven't tried, my guess is that it's not possible. In order to use .net 4.0 assemblies, the apppool running your moss site would have to be upgraded to the 4.0 version of asp.net. After that, version of system.web and other assemblies will change and I think that moss will simply stop working. But hey, it's just my guess. You can always try it out.
No. Even SharePoint 2010 is based on ASP.NET 3.5
Related
I have been wondering what technology Microsoft uses to build MS Customer 2011/ 2013? Are they using web forms or mvc?
Microsoft started development of Dynamics CRM on .NET Framework version 1.1. At that time MVC did not exist. CRM was gradually migrated to the newer framework versions (the most recent is v4.0).
The point is ASP.NET/WebForms and ASP.NET/MVC are based on very different architectures. Moving to MVC would require rewriting large parts of the application. Therefore, it is not surprising that version 2013 is still based on WebForms.
It's a combination of WebForms, HttpHandlers, HttpFilters and AJAX.
I am using some dll's from the crm 2011 sdk in a .NET 3.5 web part.The target is for SharePoint 2010 online. When I try to build it gives me the following error:
The primary reference "microsoft.xrm.client" could not be resolved because it was built against the ".NETFramework,Version=v4.0" framework.
This is a higher version than the currently targeted framework ".NETFramework,Version=v3.5". VisualWebPartProjectWebServiceTest.
I cannot upgrade my web part to .NET 4.0 because SharePoint 2010 is not supporting .NET 4.0. Is there some other solution to reference .NET 4.0 dlls in a .NET 3.5 sharepoint webpart?
I will say NO, you can't use .Net framework 4.0 dll in 3.5 but Yes in the other way around. There are a few workarounds to achieve this, but in a little different way. Check these following SO posts for further reference:
Can you use a .NET 4.0 dll in a 3.5 project?
How Can i use .NET 4.0 code in C# project which is built using .NET framework 3.5?
Making a call to a .NET 4 library from 3.5
We have a large project targeting SharePoint 2010/.NET 3.5 built against the SharePoint.dll and we plan to expand it to support SharePoint 2013 as well, but the new SharePoint uses SharePoint.dll compiled in .NET 4.5.
Is it possible to somehow share code between .NET 3.5 and .NET 4.5 projects, something like Portable Class Libraries, but between .NET 3.5 and 4.5? Or the only solution is starting new project for .NET 4.5 and using referenced files from the first .NET 3.5 project?
The .NET build target is per project, so a 4.5 solution can include a project library targetting 3.5. Your can have a 4.5 library that extends the 3.5 solution where required and your main solution can build to 4.5 and include the 4.5 library.
Thus both the 3.5 solution and the 4.5 solution use the same 3.5 SharePoint code library, but the 4.5 solution can extend your SharePoint library to take advantage of new features not available in 2010 and .Net 4.5
I have an multiple assembly C# Excel addin which passes embedded interop types across assembly boundaries. When I run this in an Excel process configured to use .NET 3.5, everything is OK. When I run this in an Excel process configured to use .NET 4.0, only controls with application logic defined in the addin assembly itself load. I think I understand why, since the handling of embedded interop types changed significantly in .NET 4.0, so that they must not cross assembly boundaries. What confuses me is that I thought in .NET 4.0 multiple instances of the CLR could be hosted in a single Windows process. If my addin targets .NET 3.5, why can't it just run in a .NET 3.5 CLR instance owned by Excel? Why is Excel trying to run my addin in .NET 4.0? It's not really an option to rewrite the addin, but it needs to install for a client who also use .NET 4.0 addins, so it's not OK to play with registry keys or the Excel.exe.config files... Any help will be REALLY appreciated!
The answer to the question in your title is 'yes'. The .NET runtime version 2.0 (which is the runtime version used by the .NET Framework 2.0, 3.0 and 3.5) can run side-by side in a process with the .NET runtime version 4.0 (which is the version number that will also be used by the upgraded .NET Framework 4.5).
However, the VSTO case is not so simple, since there is interaction between Excel and the VSTO runtime to decide what to load. VSTO 4 basically includes separate versions of the Office extensions targeting .NET 3.5 (under the .NET 2.0 runtime) and .NET 4.0. Depending on which version of the VSTO 4 office extensions you target, you uses classes (compatible with older VSTO) or mainly interfaces, so the VSTO API design and your code is a bit different too, depending on which version of the VSTO 4 office extensions you use. Then deployment and loading of your VSTO add-in depends on which version of the VSTO Office extensions you target.
So the version of the .NET runtime that your VSTO 4 add-in loads in is linked to how you made the add-in. Read more here: http://msdn.microsoft.com/en-us/library/bb608603(v=vs.100).aspx and http://msdn.microsoft.com/en-us/library/ee712596.aspx.
If you have other COM components, it could be that the COM components are activated in a different version of the runtime (say in the 2.0 runtime) and are then not accessible from the 4.0-runtime based add-in. The way COM interop type changed in .NET 4.0 would typically make things work better, since the runtime now correctly identifies types defined from different assemblies as 'the same' based on GUIDs etc.
To make life easier, I can also suggest Excel-DNA (which I develop). It is a free and easy add-in library for making full-featured Excel add-ins in .NET, without using VSTO. Excel-DNA allows you to target any version of Excel, and any 2.0+ version of .NET.
I'm not familiar with developing excel addins but yes you can do that.
However using a different versions of clr in the same process is to done automatically.
You can read the details here.
As stated here, the way evidence is loaded will change in .NET 4.0. How will this impact systems like SharePoint where you can specify exactly which permission will be granted for a dll in the wsp-package? Isn’t SharePoint using AppDomain.ExecuteAssembly(Name,Evidence) internally to make this possible, or am I missing something?
.NET 4.0 won't be used for SharePoint until the release after SharePoint 2010. We will still be on .NET 3.5 until then. So perhaps revisit this issue at a later date.