I am in a situation where the corporation has just recently upgraded to TFS 2008. They have no intention of upgrading to TFS 2010 at this time. As a development group, we've moved to Visual Studio 2010 this week. As with any large corporation, we cannot get our own environment created to install TFS 2010. Steps on too many toes, and isn't corporate standard. Etc.
I want to take full advantage of the new testing features in relation to the new UI Testing and other features. This appears to require TFS 2010. So my "dream" is to do my daily work at the office and write tests, but at night, have my code synchronized with my TFS 2010 server at home and run automated builds with the full testing capabilities enabled.
So is there is best practice for this? I've read up on the Workspace theory and the binding issues that are involved and that sounds the biggest hurdle to overcome.
Possible Solution - Create two workspaces $/WorkProject and $/WorkProject-Mirror and use a custom application using FileSystemWatcher to kick off a job that synchronizes code changes and a custom rewrite of the bindings. Use job on work laptop and home machine to allow bi-directional binding.
Research to see if TFS Integration Platform will help with this
You are correct the new testing UI (Test Manager 2010) requires TFS 2010, you are also correct that you can use the TFS Integration Platform between a TFS2008 & TFS2010 server. Then use test manager on the 2010 server.
All the above should be easy, the tough part will be the bindings in the solution file. I would suggest you have a second one created that points to your TFS2010 server so that you can open the correct solution file for the correct environment without stepping on your co-workers toes.
I think the two workspace route is overkill, it's just a solution file you need.
I wonder if you could use a read-only account to perform a get from TFS2008 and then do a check-in to your TFS2010 with a more-privileged account. I'm sure those two things and a little clever PowerShell scripting could get you what you're looking for.
I would encourage you to write a second utility to monitor that this script continues to work and to notify you if it detects a failure or something.
Related
We are having compilations problems in a TFS server and it's because the server lacks several libraries built in the default VS2012 Premium installation (Microsoft Fakes in this case).
I'm unsure of going ahead installing a full instance of VS, but first I want to know what is the best practice in this regard?
What is recommended?
Since we are talking a sandbox, do whatever and don't worry about it. If we are talking best practices, it's not a good idea to put your build tier on the app tier / data tier. Any developer could check in code that gets run on the server during the compile and trash your entire environment.
Have you looked at Visual Studio Online? It's a hosted TFS service and you can use their hosted build controller or configure your own. That makes for a very good sandbox IMO.
I don't see any issue installing VS on the TFS server(I assume you run your builds on that server too and that's when you are seeing the problem. Ideally tfs server and build box should be separate but some people use the same box.)
I have used Visual Studio on the build box several times to debug issues with builds. You just need to make sure you close the VS instance (if it has a solution open) once you are done with debugging otherwise your builds can fail when they try to clean up the project directory at the start of the build.
We run a single server TFS instance which has everything - sql, SharePoint and tfs - running on it. It is also a build server so it has to have VS 2010 and 2012 installed. We've done this with all versions since 2005 and have had no issues with it at all.
I wanted to know,
if, I can setup sharepoint 2010 server along with visual studio 2010. And sql-server on another machine in some domain
and
create multiple accounts on the sharepoint 2010 machine
and allow developers to develop sharepoint projects on the same machine with those accounts.
Also I wanted to know about version controls system like svn availability for sharepoint 2010.
in our company each developer has own development server, but some time we work simultaneously on the same server. I don't know why you need separate slq server, for development purposes SharePoint works fine with SQL express installed on the same machine. But if you wish you can use separate SQL server of course. If you would like to use specific accounts for SharePoint it is a good practice. Look at this post, there is some information about typical SharePoint accounts pool.
About simultaneous development. If you work with Visual Studio, not configuration, when you are deploying solutions server will restart IIS each time, is is not so useful for normal development of few employees. Also if you will decide to work like this, my advice to work in different web applications for each developer it will allow you more useful debug capabilities. You will not interrupt each other because of attaching to the same process w3wp. But notice, SharePoint is flexible and extendable environment, you can do I lot of things just with configuration and JavaScript development by SharePoint Designer. So if you will work most of time by configuring it will be possible successfully work on the same server for whole team.
About source control. If you are developing with Visual Studio, TFS is for you, or any other source control system, like svn or git. If you are develping by configuring with SharePoint Designer, I advice you to store some reusable functionality also withing TFS, by just copying. For other content you can turn on versioning on SharePoint libraries, so each your modification will be stored with comments if you wish.
I have team members that need to be able to checkin VBA modules/classes created in Excel 2007/2010.
I want to be able to use some TFS functionality, ideally from within the VBA IDE.
I don't want to checkin Excel files as artefacts. Ive seen the MSSCCI provider download from MS.
I don't think in this case the Windows shell extensions from the Power Toys helps because I don't want to have to create an additional process for developers to export and/or import class & module files from their work in VBA project maintenance.
Question: Can someone provide a way to use the MSSCCI provider with Excel 2007 (or even Excel 2010 only)? Do you think this would only be possible with custom VBA addin?
Update:
I've thought about using an approach such as making a custom VBA addin and adding some commands that make basic calls to the TFS client object model.
Just found this post from Codeproject from another question this time looking for the same thing but for SVN rather than TFS.
There is a Visual SorceSafe provider for VBE that comes with Office XP Developer. I used it for many years and still have it installed. It does what you want, but using VSS and not TFS.
Note that the product is not supported, but VBA/VBE has not changed since Office 2000. I used the provider for two years for Excel 2003 development with no problems.
I seem to remember recently an article describing how you can use VBA/VSS with the extra benefit of having the code also "posted" to TFS. Since I no longer professionally code in VBA/VSS, I didn't have a need for the article, but did find the topic interesting.
Office XP Developer has a few other tools that make it worth the time to install.
Access Source Code Control and Team Foundation Server
Today's guest writer is Mike Sullivan - a tester on the Access team
With the release of Visual Studio Team System 2008, we've recently received questions from several customers regarding whether or not Team Foundation Server (TFS) can act as a source code control provider for the Access source code control (SCC) component. The answer is yes!
Although many folks refer to Access’ source code control component as “SourceSafe integration,” that only tells part of the story. SCC integration within Access is fully compatible with any provider that implements the Microsoft Source Code Control Interface (MSSCCI). Although Visual SourceSafe is one of the more widely used MSSCCI providers, there are several other products that implement this interface, including Team Foundation Server 2005 & 2008 as well as IBM ClearCase.
However, MSSCCI support in Team Foundation Server is not native and requires an additional add-in available for download:
MSSCCI Add-in for Team Foundation Server 2005 http://www.microsoft.com/downloads/details.aspx?FamilyId=87E1FFBD-A484-4C3A-8776-D560AB1E6198&displaylang=en
MSSCCI Add-in for Team Foundation Server 2008 http://www.microsoft.com/downloads/details.aspx?familyid=faeb7636-644e-451a-90d4-7947217da0e7&displaylang=en
Of course, to enable SCC functionality from within Access, you’ll also need the Source Code Control add-in. This shipped as a free download as a part of the Access Developer Extensions for Access 2007 and as a separate free add-in for Access 2003:
Access 2007 Developer Extensions http://www.microsoft.com/downloads/details.aspx?FamilyId=D96A8358-ECE4-4BEE-A844-F81856DCEB67&displaylang=en
Access 2003 Source Code Control Add-in http://www.microsoft.com/downloads/details.aspx?familyid=2ea45ff4-a916-48c5-8f84-44b91fa774bc&displaylang=en
If you’re interested in taking this configuration for a whirl, you might want to download the Team Foundation Server Virtual PC image that has been made available by the Visual Studio team. Included on this virtual PC are copies of Visual Studio Team System 2008 and Office 2007 Enterprise SP1 (though Access is not installed by default on this image – you’ll need to go to Add/Remove programs within Control panel and launch setup to install Access). This trial image is good through December 31, 2008.
To get the Virtual PC image working, you’ll also need to install the Access Developer Extensions (the MSSCCI add-in is preinstalled). Since VSS is the default MSSCCI provider on the machine, you’ll need to tweak a registry key to get Access to use Team Foundation instead:
Path: HKEY_LOCAL_MACHINE\SOFTWARE\SOURCECODECONTROLPROVIDER
Key: ProviderRegKey
Value: SOFTWARE\Microsoft\Team Foundation Server MSSCCI Provider
Hopefully those of you curious about support for TFS have had your questions answered!
Can Sharepoint apps be developed in a Visual Studio 2010 dev box only or does the dev box need to connect to a Sharepoint server? Can the Sharepoint Server be a stand alone machine (no domain controller between the two machines)?
The best practise for SharePoint development is to use a virtual server that contains the SharePoint install itself (and a copy of the portal you're working with), because assuming you are programming directly against the SP API, you will need to be executing your code on the machine that contains the Sharepoint installation itself.
You can program against SharePoint from a non-SharePoint machine through the use of the standard set of SharePoint web services provided, and you can of course create your own services (again sitting on the SP box/VM) to interrogate too. The catch to this approach is that you'll be dealing with return types that are primitive or XML based and you won't have the luxury of SP objects, for example SPUser, SPSite, etc, but for simple query operations at least this is not a bad approach.
IMHO, however, you've far greater flexbility programming against the API itself (Microsoft.Sharepoint.dll) so I'd advise you to get a VM going with all the necessary installs. Yes, it's a pain and time-consuming to set up, but well worth it.
As for Stand-alone options: SharePoint 2007 is not supported on anything non-server in terms of OS, so you'll need something like Server 2008 in order for it to work. SharePoint 2010, however, whilst claiming to only work on Server 2008, can actually work on Windows 7 (Pro and above) with a few hacks. You also have the benefit of 'sandbox' feature deployment in 2010, where you don't in 2007, meaning dev work is more cleanly isolated and less of a risk to a farm as a whole.
Good luck!
You can develop for SharePoint 2010 using VS 2010 using a stand alone setup - this is supported by Microsoft and very much recomended. Infact most of the tools built into VS2010 that will make your life significantly easier will only work with a local copy of SharePoint 2010.
MSDN - Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7...
Yes, if you have Windows 7 or Vista (you need WAS - Windows Activation Services). We have tried it but found that it was better to develop on a Windows 2008 with your own AD.
It will depend on what you are developing, for webparts you will not notice the difference. You will notice the difference when working on the security part og the app.
Sahil Maliks book has a whole chapter on the different options.
you can do sharepoint development by copying certain dlls to your local enviroment but to my understanding this is unsupported and the recommended practice is to use a virtual machine or development on the machine in which the service resides.
Recently I had to develop a SharePoint workflow, and I found the experience quite honestly the most painful programming task I've ever had to tackle. One big problem I had was the problems I encountered when I had to step through it in the debugger.
There's an article on how to debug a SharePoint workflow here that tells you how to set breakpoints etc. This involves copying the .pdb file into the GAC alongside the .dll file containing your workflow. You have to do this from a command prompt (or a batch file) because Windows Explorer doesn't let you view the relevant subdirectory of c:\windows\assembly.
However, if you do this, the next time you try to deploy the workflow from within Visual Studio, it complains that it can't be deployed because "the file may not be signed" and if you attempt to copy the new version of the dll into the GAC, it tells you that the .dll file is locked.
I've found that some of the time, you can get round this by doing an iisreset, but on other occasions you have to restart Visual Studio and there have been frequent times when I've even had to reboot the computer altogether because some mystery process has locked the file. When I don't use the debugger, on the other hand, everything works just fine.
Does anyone know of a simpler way of debugging workflows than this?
I've got a lot faster developing SharePoint-Solutions in general (not only Workflows) when i started using WSPBuilder. WSPBuilder has a Visual Studio Addin called WSPBuilder Extensions and in my opinion the WSPBuilder Extensions do a better job than the infamous Windows SharePoint Services 3.0 Tools: Visual Studio 2008 Extensions, Version 1.2. Thanks to the WSPBuilder Menu deploy/upgrade/uninstall of a solution is just one click away!
The SharePoint team is currently working on MOSS extensions for VS 2008 which will allow this type of functionality. This was available in VS 2005 with MOSS extensions, but has to be run off Windows Server with a full MOSS installation and the correct permissions set.
One thing that would really help is if the SharePoint team provided interfaces for the SP-specific workflow services needed to run SP workflows. This would allow you to mock those interfaces and run the workflows outside of SP proper. AFAIK, you can't do that today.
I've personally found SharePoint extremely painful to develop against... not just with workflows, but overall. I understand the administrative wins and the end user productivity, but it's a fairly dreadful experience for Joe .NET Developer.
As for speeding up the IIS reset, Andrew Connell has some tips here as well
http://www.andrewconnell.com/blog/archive/2006/08/21/3882.aspx
This brought my IIS reset time from 10+ seconds down to less than 2 seconds.
I'm not sure you need to get the pdb file into the GAC. (At least, the fix I'm about to describe works just fine for debugging SharePoint web parts in VS2005, which have a similar problem.)
There's a checkbox marked "Enable Just My Code (Managed Only)" in Tools-->Options-->Debugging; if you uncheck it, then Visual Studio will happily load your pdb's from the bin\Debug folder where it built them. Probably. Can't hurt to try, anyhow...
Check out STSDev on CodePlex by SharePoint MVPs like Ted Pattison, Andrew Connell, Scot Hillier, and more.
STSDEV is a proof-of-concept utility application which demonstrates how to generate Visual Studio project files and solution files to facilitate the development and deployment of templates and components for the SharePoint 2007 platform including Windows SharePoint Services 3.0 (WSS) and Microsoft Office SharePoint Server 2007 (MOSS). Note that the current version of the stsdev utility only supports creating projects with the C# programming language.
Keith