We would like to upgrade our clients to VS 2012 without upgrading the TFS server which is TFS 2008. Also, since we have several products, we want to modify the code to be C++11 compatible one product at a time. So the TFS server will have to support and issue builds for both VS 2008 and VS 2012 clients. Does anyone ever configured a TFS 2008 to work with two build servers? Is it even possible?
Related
I'm new to TFS on Visual Studio 2012 and I found the TFS 2013 Express edition to install. The thing is my friend and I are working on a project and we wanted to sync our version to either of us computer. Currently, we don't have a server to say but is it possible to use one of our computers as a server and install TFS on it and sync our projects? Does it require Internet connectivity whenever we want to sync? Can we use local area connection to do the sync? Do we need TFS to be installed on both of our computers?
A link to installation guideline would also be helpful.
Thanks
This is the guide you need to plan your Team Foundation Server installation:
http://www.microsoft.com/en-us/download/details.aspx?id=29035
TFS works perfectly well over a LAN. At the end of the day it's just a HTTP server, so as long as either you and your friend are on the same network, or if not, the necessary ports are open on the router, he can connect fine via the internet. Doesn't matter which one of you hosts it.
You do not need TFS on both computers, Visual Studio will happily connect to it once you provide the details (Access from the Team Menu, and Team Explorer).
So I have a suite of SSIS packages that we created using Visual Studio 2008 and are currently deployed on a SQL Server 2008R2 instance. However, I would like to upgrade these to 2012 via SQL Server Data Tools for Visual Studio 2012 which is easy enough, however, the company that I work for does not have any plans to upgrade the SQL Server to 2012 any time soon. So is there a way to create SSIS packages using SSIS 2012 and deploy them to a SQL Server 2008R2 instance while maintaining all of the new features of the SSIS 2012 package. IE Project Connection Managers and Package Parameters, etc...
Unfortunately, no. The Integration Services Service, the engine that which makes the package go, would have to be installed on the machine to be able to interpret/run them. Furthermore, unless you planned on running the packages from their .ispac containers, you wouldn't be able to take advantage of the rest of the "goodies" like the Environments, at least not without writing some ugly exec calls.
Also, if you think about slipping the IS services on that box, it is my understanding that's a SQL Server license consumed and given the ugliness that is the new per core licensing model on 2012, I wouldn't be happy writing that cheque. Not saying you'd do that, just a headache I saw at a client site when the auditors stopped by.
Where I currently work we are using TFS2010 and already have a build controller set up on a Windows Server 2008 R2 box. We are contemplating upgrading our TFS2010 instance to TFS2012, but in the meantime we are about to start development on a new product. The project team have established that it would be a good idea to create a new build server for this new product for the following reasons:
Our current products are .NET 3.5 solutions
The new product will be a .NET 4.5 WPF solution
Preference to install third-party components and tools required by the build of the new product in an environment separate to our current build server so as not affect the building and release of service packs and hot-fixes of existing products.
Can a TFS2010 build controller be installed on a Windows Server 2012 machine, and what are the things that I need to look out for? Or is it more advisable to install a new controller on another Windows Server 2008 R2 machine, and when we have upgraded to TFS2012 to upgrade the controller on the new server, and perhaps upgrade the server to Windows Server 2012 as well?
Installing TFS 2010 build controller in Windows Server 2012 was pretty simple. Note that .NET 3.5 needs to be installed on the build server before installing TFS 2010 build controllers.
Also if building .NET 4.5 applications, and are not keen on installing Visual Studio 2012 on a build server, the Windows 8 SDK should be installed.
Furthermore I would recommend installing MSBuild Community Tasks (https://code.google.com/p/msbuildtasks/downloads/detail?name=MSBuild.Community.Tasks.v1.4.0.56.msi&can=2&q=) for extra MSBuild functionality. This is especially beneficial for applying a version number to your assemblies by obtaining build number values from whatever automated build server technology you are using and supplying these values as parameters to MSBuild. The following article demonstrates this using the Bamboo CI server product: http://itrathnasekara.blogspot.com.au/2011/05/setting-assembly-version-automatically.html.
I recently setup a sharepoint server 2013 on our company and have found really good examples how you can override the suitbar with custom links.
Now that I'm trying to implement those examples i get to that point where Visual Studio 2012 and Office development tools is installed.
When i choose to start a new project I select New Project > Templates > Visual C# > Office/SharePoint > SharePoint Solutions > SharePoint 2013 Empty Project hit ok and i get an error that says Sharepoint not installed?
Am I supposed to install VS 2012 and develop om my Sharepoint 2013 server directly?
A very common way to develop SharePoint applications is to run a virtual machine (hyper-v under windows 8 for example) on your development workstation.
You can also dual-boot into a vhd file.
You can also install Windows Server 2012 and use one of the many desktop conversion techniques to use it as your primary operating system on your workstation.
Another often seen technique is to have a virtual machine hosted in the cloud or a datacenter, running both SharePoint Server and Visual Studio. Then connect to that machine using Remote Desktop.
With some trickery, you could have the SharePoint 2010 installer install om a workstation OS. This no longer works on SharePoint 2013. The reason this support was removed is due to the inclusion of Boot from VHD and Hyper-v into Windows 8.
It is my experience that if you just want to build your application and not run or debug it, that just having the assemblies copied over from an actual SharePoint Server will allow you to do that. I haven't found an updated document for SharePoint 2013 yet.
Yes. You have to develop on the sharepoint server directly using Visual Studio as Sharepoint server GAC has the required server object models to work programatically with sharepoint server object model.
You can aslo develop on client machine using Client Object Model or WCF Data Services Framework.
I know there are so many questions and articles on this topic and I have searched hours and hours on the Internet so far, but I still couldn’t find the right answer for my question. I was assigned the task to investigate the development environment for SharePoint web parts by my company. The money is not an issue but it must be the proper way to do it.
Here is my ideal plan: at developer desktop, install VS2005/2008 (it is already installed), VS2005/2008 Extension for SharePoint and WSPBuilder. It is also installed a Virtual Machine and the VM runs windows server 2003/2008. WSS3.0 and SQL Express 2005/2008 will be also installed on VM.
Developer’s desktop is a web parts development environment. Developers use VS to develop the SharePoint web parts and then run the WSPBuilder, it will deploy the web parts into the SharePoint testing environment on VM. So the VM is just a SharePoint testing environment.
It looks like a good idea, however, it doesn’t work. Why? Because VS extension can't be installed on developer’s desktop as it doesn’t have WSS3.0 installed!
I definitely don’t want to install the VS on the VM, because our developer desktop has installed VS and we don’t need to have 2 VS licences for 1 developer.
Any idea what is the best way to set up the development environment for SharePoint web parts?
Thank you in advance.
You won't be able to develop for SharePoint (WSS 3.0) unless your development environment includes an installation of at least WSS. In general, development is done on a Windows Server 2003 Virtual Machine (Visual Studio is installed directly on this machine). However, SharePoint can be installed on Windows Vista and Windows 7 machines, so your development machine may be able to host SharePoint itself, but it is far easier to do this on a VM.
My SharePoint development VM has the following installed:
Windows Server 2003 R2
SharePoint 2007 (Including SQL 2005)
Visual Studio 2008
Visual Studio Tools for Office
Office Server SDK
Visual Studio Extensions for WSS 1.3
Obviously you can use WSPBuilder instead, but I much prefer VSSWSS 1.3, but that is developer preference.
I believe (should be verified with Microsoft) that the licensing for Visual Studio can be extended to Virtual Machines when used by the same developer (depending on your agreement).
An alternative for you which may or may not work depending on your priorities.
Install Visual Studio 2010 and SharePoint 2010 Foundation to your development server.
Grab a copy of Microsoft.SharePoint.dll from a SharePoint 2007 server.
Use VS2010's tools to develop a web part but manually change the reference to the 2007 dll's (+ also see "Build a SharePoint 2007 Web Part with a Visual Studio 2010 Visual Web Part Project") so you are outputing a 2007 compatible web part.
When you delploy your 2007 web part to your local 2010 server it will just work (as its backwardly compatible)
When you deploy your 2007 web part to your test/qa/production servers it will work too.
Advantages
You're working with latest greatest
version of VS and the sharepoint
tooling so you get one click deploy,
automatic creation of WSP packages
etc. Nothing against WSP Builder etc (they are great) but my moneys on vs2010 sharepoint extensions for the future.
You're ready if/when your
company moves to 2010.
You're developing on a Windows 7 machine, not a 2003/2008 server and or a VM so this has advantages for licensing, speed and ease of use (dual monitor support from VS running on a VM?)
Edit - to deploy web parts to other servers you create a .wsp package and then deploy via STSSADM or another tool (SharePoint solution installer or other admin tools).
I haven't used VSSWSS or WSPBuilder. I've always used STSDEV for SharePoint 2007. And I've always used Windows XP to do it. I don't know if VSSWSS and WSPBuilder act the same, but, as Ryan was saying, I copy whatever SharePoint DLLs I need from a SharePoint 2007 server into a Solution Folder in my Visual Studio solution. I then select Add Reference in my project and browse to the DLL.
In four years, I've never had any problems with this method. The solution packages build just fine and work on any SharePoint server. I lose the option to debug, but I'd rather stay on my machine than go into a VM or Remote Desktop.