Visual Studio 2015
Visual Studio 2015 has been released 😀 https://www.visualstudio.com
A detailed comparison of the version is available here.
Visual Studio 2015 has been released 😀 https://www.visualstudio.com
A detailed comparison of the version is available here.
Having a server at home that hosts a TFS is nice. But really necessary? Not really. So I decided to move all my sources to Visual Studio Online.
Visual Studio Online Basic is free for the first 5 users. That’s enough for me.
The migration process is straight forward easy with a tool that is installed on my computer. The process is described here. Another post can be found here.
During the pre migration steps a user mapping is performed, connections verified and a few other things. The process itself takes some time. I have 32MB in 4680 files and it took about half an hour. Another service on my server that isn’t needed anymore 🙂
Conclusion: Migration from On-Premise TFS (in my case 2012) to Visual Studio Online is very easy.
In this post I will show you how you can use MSBuild to target your project for .NET 3.5 or .NET 4.0 and use a separate app.config file for each.
My Warmup Tool is supposed to work with SP2010 and SP2013. To achieve that compatibility, I have to change the TargetFramework of the project to be able to compile, as well as the app.config so the application uses the desired Framework. I didn’t want to change the values every time manually. An automated solution has to be possible. And it is. Some little changes to the project file and MSBuild will do all the work for you 🙂
So lets look into the default .csproj file, which sets the TargetFramework and references the app.config.
1: <?xml version="1.0" encoding="utf-8"?>2: <Project DefaultTargets="Build" xmlns="http://..." ToolsVersion="4.0">3: <PropertyGroup>4: <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>5: <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>6: ...7: <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>8: ...9: </PropertyGroup>The version has to be exchanged, because SharePoint 2013 uses the .NET Runtime 4, but SP 2010 the Version 2. Trying to build the project with the wrong Target Framework will fail. The referenced SharePoint Assemblies depend on the correct Framework Version.
An easy way to specify the value depending on a condition, is to use the Constants, you can define on the build page within the project settings.
I use “SP2010” and “SP2013”, which can be used by MSBuild. You can change that value any time. Reloading the project is not necessary, as the Build-process picks up the value when it needs it.
Let’s get back to the TargetFramework. Switching the version depending a constant defined (“SP2013” in my case) is done with two new property groups in the csproj file of your project. I’ve included the lines below the debug/release Property Groups, because the DefineConstants property is defined there.
1: <PropertyGroup Condition=" $(DefineConstants.Contains('SP2010')) ">2: <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>3: </PropertyGroup>4: <PropertyGroup Condition=" $(DefineConstants.Contains('SP2013')) ">5: <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>6: </PropertyGroup>Remove the default entry, which is the one you see on line 7 of the previous code fragment above.
Now we are set up, and may compile the project for .NET 3.5 and .NET 4.0. Great. To have the application config include the supportedRuntime version as well, I’ve included two config files into my project.
The files are identical, except the value of the supportedRuntime, which is v2.0.50727 for .NET 3.5 and v4.0.30319 for .NET 4.0. Again MSBuild is your friend for using one or the other file depending the previously used constant “SP2010” or “SP2013”.
The switching condition can be specified like this:
1: <ItemGroup Condition="$(DefineConstants.Contains('SP2010'))">2: <None Include="Config\2010\app.config" />3: </ItemGroup>4: <ItemGroup Condition="$(DefineConstants.Contains('SP2013'))">5: <None Include="Config\2013\app.config" />6: </ItemGroup>The default entry for including the root-level app.config file has been removed from the csproj file.
As a result of the effort, I can build my console application for SharePoint 2010 and SharePoint 2013 by switching the constant in the project settings. The corresponding app.config file is used as well.
The new release brings support for Visual Studio 2013 🙂
The CKS – Development Tools Edition for Visual Studio 2012 and 2013 is a collection of Visual Studio templates, Server Explorer extensions and tools providing accelerated SharePoint 2010/2013 development based on Microsoft’s SharePoint 2010/2013 development tools.
http://visualstudiogallery.msdn.microsoft.com/cf1225b4-aa83-4282-b4c6-34feec8fc5ec?SRC=VSIDE
Visual Studio allow a F5 Deployment. I guess you all know that. The part where you have to think carefully is, when you add Features to your project.
Should you activate “Activate On Default”? Well, it depends (as always). Usually I don’t enable that setting, because features tend to be activated on scopes you won’t expect.
Take a WebApplication scoped feature for example. It might create SafeControl entries for your controls. Do you really want them to be added to an Extranet WebApplication if your solution is solely for an Intranet Application?
The problem does not exist for you, if you auto activate your features and have set your deployment configuration to “Default”. But in my case, I use “No Activation” and “Activate On Default = false” most of the time. Then, after you deploy an update of your solution, SharePoint retracts and re-adds the solution. The consequence is a deactivate feature 🙂 (in case of Farm and WebApplication scoped features).
CKS rocks! What’s that have to do with this?
The CKS Extensions for Visual Studio (http://cksdev.codeplex.com/) can Update the solution like you would do via PowerShell or stsadm with a new Deployment option named “Upgrade Solution (CKSDev)”.
Unfortunately CKS isn’t available for Visual Studio 2013 preview. So I had to do something else to avoid the problem with non activated features after deployment.
Fortunately Microsoft provided some Command Line action for post-deployment. And since the SharePoint URL is known from the properties of the project, it can be used via variable $(SharePointSiteUrl). Combined with stsadm to activate the feature, I had all I needed.
So for now, Deployment from VS will work again 🙂
One of the first things I used to tell guys new to SharePoint development is: Never ever name the folder of your feature “Feature1”. If you create a solution with WSPBuilder, or did some time ago with VS 2008, you have to rename the folders immediately!
This is how a typical SharePoint project looks like, if you create features. I guess most of us have used the mighty WSPBuilder (http://wspbuilder.codeplex.com) for developing with SharePoint.
After building the VS solution and creating a WSP package with WSPBuilder, the wsp contains two folders. They reflect the names, we defined in VS.
Now lets take a look at the same features in a Visual Studio 2010 SharePoint Solution.
It almost looks the same as a WSPBuilder solution in VS 2008.
The features have been created by right-clicking on the Features folder in the Solution Explorer. This is important.
In many places VS uses tokens to replace strings with certain solution specific values like the assembly name. You can take a look at the tokens here: Replaceable Parameters
If we look at the wsp again, we notice the difference. Visual Studio 2010 has added the solution name as prefix to the feature folders. Great. Thank you Microsoft. Now we can name our feature folders e.g. after the scope. (Site, Web, Webapplication of Farm), and do not have to worry about duplicate names.
The magic of this can be seen, if we take a look at the properties of the feature folders.
Conclusion: VS 2010 is a great improvement to us SharePoint developers. We don’t have to know all the places where it helps, but it can’t hurt, either. I hope this article brings a little light to the magic 🙂
The RSS Feed Product Index offers a feed with new KB articles for many products.
SharePoint relevant feeds are:
Some SQL feeds:
And Visual Studio
A quick test shows that the just released Visual Studio 2010 works on my SP 2010 Beta 2 VM.
I could open a project, hit F5 to deploy it and debug successfully.
I’ve just seen that the RC is available via MSDN.
Silverlight 4 is not supported in the RC it says in the notes. Have to try SharePoint Development against the Beta 2…
As you can read on the Microsoft SharePoint Team Blog, a new version of the Visual Studio extensions have been released. This version is Community Technology Preview. And wow… yes… finally… x64 support!
The download is available here.
The final release of VSeWSS 1.3 is planned for the North American Spring of 2009.
Yes. Both Fortress and Vault are free for use by a single user. Simply install the product and do not enter any serial numbers at all. When no serial numbers are present, Fortress and Vault behave as if there is exactly one user license. Note that this free license does not apply when the product is used by more than one person. If you have two people who need to use Vault, you will need to purchase two initial licenses. If you enter a serial number containing only one license, then the product will still have exactly one license present.
So don’t waist your time anymore hassle around with different version of you projects (which are of coarse SharePoint projects 😀 )
Warning:
Setting up the TFS is not an easy task. In our environment we have the Reporting Services and WSS installed on the TFS server. The TFS and SharePoint databases are on a separate SQL Server. Reporting Services databases are locally stored.
If you now try to install the SP1, it will reconfigure your Reporting Services so that the databases are on the remote SQL Server. Of course that won’t work! So the upgrade fails with an error
Returning IDOK. INSTALLMESSAGE_ERROR [Error 29112.Team Foundation Report Server Configuration: Either SQL Reporting Services is not properly configured, or the Reporting Services Web site could not be reached. Use the Reporting Services Configuration tool to confirm that SQL Reporting Services is configured properly and that the Reporting Service Web site can be reached, and then run the installation again. For more information, see the Team Foundation Installation Guide.]
So what. We will continue with RTM and without the SP1. At least I was thinking that way. Well, obviously the TFS did otherwise. The TFS was completely offline!
To fix the problem I had to do a repair installation through Add/Remove Software. During that process I had 4 or 5 warning that the Reporting Services are not configured, because the database server was changed again to the remote SQL Server! But you can reconfigure the Reporting Services to use the local databases and then continue the wizard.
To be short: If you have a non default installation of your Team Foundation Server 2008, think carefully about applying the SP1.
The SP1 is available through MSDN. See http://blogs.msdn.com/msdnsubscriptions/archive/2008/08/11/visual-studio-2008-service-pack-1-files-are-also-now-available.aspx and http://msdn.microsoft.com/en-us/vstudio/products/cc533447.aspx
You will need it to install the Reporting Services 2008 add-in into your existing Visual Studio 2008 installation.
You can download an overview for Default Visual Studio 2005 Shortcuts for C+ here.
If you want to write your own Webpart, you can start from scratch with a Class Library, or use the templates from http://www.microsoft.com/downloads/details.aspx?FamilyID=19f21e5e-b715-4f0c-b959-8c6dcbdc1057&DisplayLang=en
The downside of this VS templates is, that they can only be used on a computer, which has SharePoint installed, and you cannot open a project created with the VS templates with a VS on which the templates are not installed.
Ishai Sagi wrote a great article about Webpart development. His article is about server side controls and data binding in Webparts.
Here is the link to his great article: http://feeds.feedburner.com/~r/sharepointmvpblogs/~3/106217340/server-side-controls-and-data-binding.html
Mike Ammerlaan shows in his article how to integrate Ajax in SharePoint, and how to create a simple Ajax Webpart.
He also explains how to use UpdatePanels with Ajax, and how to disable the default SharePoint form action.
Quote:
In this post I’m going to explain how to start using ajax in your web parts. The goal of this article is to reproduce functionality similar to the KPI and BDC web parts in MOSS 2007. If you don’t know what ajax is or the basics of how it works this article is probably not for you.
http://sharethispoint.com/archive/2006/11/15/Build-web-parts-with-ajax.aspx