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.
Related
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.
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'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
There were a lot of promises and hopes, but did MS actually get around to including ASP.Net AJAX in either WSS3 SP1 or MOSS SP1? None of the release notes mention it...
No, ASP.Net AJAX is not included in either Service Pack.
ASP.Net AJAX was included with .net 3.5.
As far as I remember it wasn't included in WSS3 or MOSS SP1.
BTW WSS3 & MOSS SP2 is now out (and I don't believe it was included in that either.)
It's not that hard to get setup, you just need to make some interesting additions to your web.config, and master pages.
In my experience ASP.NET AJAX must be installed by itself (it hasn't been included in anything I have installed). Here is the download link for the installer.
Follow this article to get it loaded into the SharePoint web.config files.
Does anyone use the MS SharePoint Solution Generator and VSeWSS 1.2 in a multi-developer environment with source safe? We are having issues re-deploying (because it doesn't really upgrade the solution with stsadm). It keeps saying the same feature is already installed - which it is, but it should retract the feature and re-install it - which it doesn't on some machines. Something is messed up with the feature's GUID but we can't find where that might be. One dev will be able to deploy and re-deploy but then the next dev won't. Where does VSeWSS 1.2 change the GUIDs? ARG!!!
We see the nice deployment targets (upgrade, etc) in STSDev but we're reluctant to use STSDev or the other codeplex tools because they are not supported by Microsoft. We have Visual Studio 2005 but not the money to upgrade to VS 2008 to get VSeWSS 1.3 - bummer.
---UPDATE----
I think we found a bug in VSeWSS that other's have commented on: Editing the projects properties resets some feature GUIDs.
It might also be a problem with the scope of the install. How do we get a site definition to install to the FARM scope in VSeWSS 1.2?
Don't worry too much about supported by Microsoft too much. While it is a consideration, the end result of MS SharePoint Solution Generator (terrible) and VSeWSS 1.2 are still SharePoint solutions and all solutions need to contain the same xml.
Could the deployment targets for STSDev be modified to work with your VSeWSS solution? After all, the deployment targets here are just working with STSAdm and a solution file.
In order to avoid the usual "works on my machine" you should set up a build and deployment system. If you are using virtual server or ESX server it should be fairly simply, and cheap as well. You should be able to use open source software all the way if you have more man power then money.
VSeWSS 1.2 and 1.3 store the feature GUID's in files in the /PKG directory of your Visual Studio solution. If you delete these files, or check our project into Source Control without these files and check them out on another machine, you will lose your GUIDs. Sure, VSeWSS will recreate the missing files for you, but it will do so with new GUIDs and new feature names.
A common requirement is to add the /PKG directory to your Visual Studio 2008 project and get it into source control.
You can read more about the files in the /PKG directory in the Release Notes for VSeWSS 1.3 here.
PS: We did some improvements to the Solution Generator in VSeWSS 1.3, but it wont generate a 100% perfect solution for you.