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.
Related
I have been tasked with setting up a SharePoint 2013 site being a straight MVC developer has me scrambling to figure out how to implement a solution that works for everyone involved.
We have a server with SharePoint on it and visual stuido however RDC only has 2 connections (company will not pay for more connections, tried that route) and we have the potential for 8 developers to be logged in at once.
our local machine setup is windows 8.1 with visual studio 2013 on it.
I read somewhere you can do remote connections to SharePoint but have no clue how to set that up or if it's even possible for use.
if anyone can help point me in a direction that would be great.
If you are strictly developing Apps you can develop remotely and this TechNet covers the step-by-step for it (configure the server and infrastructure for Apps, create a developer site and give your Devs the required permissions).
If you want to develop components that use the server side Object model (Microsoft.SharePoint.dll) you MUST do so from a SharePoint server.
You can try to copy the DLL over to your dev machine, and you can successfully build. With this, though, you will lose many of Visual Studio's integrations and will not be able to deploy or debug from Visual Studio
I think I misunderstood the whole Azure development concept. I thought I could run the Visual Studio IDE within Internet Explorer or something along those lines.
You can, but you'll use an RDP client (like mstsc.exe) instead of internet explorer. You can create a Virtual Machine in Azure that has visual studio installed on it and develop on that VM. There are a number of images already in the platform that support this scenario if you're an MSDN subscriber, I believe.
Even if you're not an MSDN subscriber, you can create a VM and set it up for development yourself. Then you can use your remote desktop client to log into that machine from anywhere and develop on it instead of your local box. This isn't limited to a Window dev env't either, of course.
I use this in scenarios where I have a constrained laptop but good connectivity and a desire to get some work done. You could use this to develop with a full IDE from a Surface RT, e.g. :)
I think I misunderstanded the whole Azure development concept, I
thought I could run Visual Studio IDE within Internet Explorer or
something
Azure is a web hosting environment in a nutshell. I think you are talking about Visual Studio Online in which you can run VS IDE inside browser.
Once you finish writing code in Visual Studio Online, you can deploy it to Azure.
Visual-Studio-Online-Monaco
channel9 - Visual Studio Online Monaco
Firstly, apologies that the question is not strictly about programming, but how to simply promote an Azure website through environments. If anyone can suggest a better place for this question to be posted then please fee free.
Scenario
I have a two Azure website environments. Lets call them:
www.myTestSite.com
www.myProductionSite.com
I am using Visual Studio 2013 and am using TFS on Visual Studio Online.
I have managed to configure everything to the point where I can check in to TFS and on a successful build, automatically deploy to www.myTestSite.com.
The files are saved in a 'Drops' folder on Visual Studio Online (TFS). It all works great up to this point.
What is the simplest way of then taking one of these successful builds and promoting it to www.myProductionSite.com?
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.
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