Microsoft CRM 2013 Webforms or MVC - dynamics-crm-2011

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.

Related

TFS 2015 Integration with SharePoint 2016

Is TFS 2015 is compatible with SharePoint 2016? Google search shows it is not compatible but didn't find any updated reference.
It's probably not compatible. The TFS integration with sharepoint is, at this point, more or less abandoned in favor of more flexible built-in dashboards, graphing, and reporting capabilities. You can still use Sharepoint for document management without having it explicitly integrated with an instance of TFS. I always recommend examining what you're using Sharepoint for in the context of TFS. I think you'll find that it's unnecessary to have it integrated.

using entity framework 5.0 with sharepoint 2013

I want to use entity framework 5.0 with sharepoint 2013. When I deploy a simple web part I get "entity framework 5 could not load file or assembly entityframework version 5.0" error.
Can I use entity framework with sharepoint 2013? If so what is the problem?
Thank you.
Note:I can use ef5 in web projects, in addition I have another machine setted up sp2010 and entity framework 4.0. They work fine.
on the package manifest add the entity framework to the safe controls, this will add the safe control in the web.config of the corresponding sharepoint web application.
I made a work around and use WCF services to connect database.

How to deploy SharePoint solutions using different versions of ajax extensions in a common SharePoint server?

We have a common SharePoint server which runs an internal SharePoint site. Our teams deploy their SharePoint products in the server and add it to our site. Some products user .net framework 2.0 and some products use .net 3.5. So they enable ajax extenisons for the site for .net 2.0 which adds the entries for the assembly System.Web.Extensions version 1.0.61025.0 where as our version will be 3.5.0.0. Because of the difference we get an ambiguous error while running the web site.
How can we deploy different products using different versions of Ajax extensions in the same site?
You should upgrade all your servers to 3.5, any other workaround is useless now. If you still have to do that, I would compile everything under 1.0.61025 and add to the web.config of the servers running 3.5 entries mapping dll versions (just like they do in SharePoint 2007 for mapping DLL for web parts compiled under SharePoint 2003, take a look at the web.config, it's self-explanatory.

Can I use .NET 4 with SharePoint 2007?

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

Impact of changes to the CAS policies in .NET 4.0?

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.

Resources