Our team is going to be developing against SharePoint using local VMs. Our VMs are not allowed to join the host domain. Additionally our host nics are prohibited from using Internet Connection Sharing. We have a requirement to source control all our development work using Team Foundation Server. Our TFS installation is using Kerebos for authentication.
To be able to use TFS for source control we were thinking we could share a folder between the host and VM, do our work on the VM, save to the shared folder and then do check ins and such from the host which will be able to authenticate against TFS.
I'm hoping there is a cleaner way to do this or someone with similar restrictions can provide some insight.
Note: I have successfully setup a similar mechanism using Tortoise SVN and Ankh SVN that works, but management will not budge on the TFS requirement. Not that I blame them either, the license is very expensive and they want to feel they are getting their money's worth. Therefore TFS has to be included in the answer.
Here's a solution that works perfectly for SharePoint 2007 development.
We run virtualised instances of Windows Server 2008 on our Windows XP machines at the project i'm on. We use Sun VirtualBox as the virtualisation software.
secondly, each VM is a standalone domain controller + sql server + reporting server + analysis server + sharepoint server and as such isn't joined to the main domain.
when opening up Visual Studio 2008 and connecting to TFS you don't need the machine/server to be connected to the domain as the VM NATs through the host machines network adapters - use a fully qualified address for your TFS and you shouldn't have any problems connecting to TFS from within the VM.
you may need to turn off integrated windows authentication (IE -> Tools -> Internet Options -> Advanced)...
We also run VS08 in the VM and not on the host..
Another thing is to use WSPBuilder to build your solutions and create the deployment scripts for you (or alternatively just set up an external tool/command from VS08 that runs the stsadm.exe -o deploysolution command)..you can deploy effortlessly to the VM and ensure that it runs fine - then just check in your code, set up build scripts that fires off WSPBuilder on the build server to build the solutions for you and deploy from there (or copy the WSP up to the server and run them there).
I think your solutions is as clean as it will get.. you could map a folder on your host machine and open the Visual Studio project straight from there within the VM. Saves copying. Committing will have to be from the host. Use of TFS features will be a bit awkward, you'll have to open VS on your host machine as well to connect commits to work items etc. Not exactly what the investment in TFS was for.
How come they've dished out the cash for TFS but are not willing to facilitate it? The VM's should really be in the domain.. or at least a trusted domain.
We run the same setup except we do have SVN and can commit directly from the VM. Workable :)
BTW, if you develop for SharePoint 2010 this gets better; it'll allow installation on non-server OS's so you can develop on your local machine (which I guess, is on the domain).
I generally use VS2008 running on the host with the SharePoint assemblies installed to the GAC of the host. I use build events/build targets with a shared folder and sysinternals to build directly to the SharePoint VM's bin/GAC folders. This way Visual Studio builds directly to the SharePoint server and you do not have to manage 2 installations (host and VM). I would also recommend installing VS2008 debugger as a service on the VM for easy debugging.
Hope this helps!
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'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).
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'm running Visual Studio 2010 and IIS 7.5
My site accesses a specified servers hardware for some statistical analysis.
When I debug my site in Visual Studio, I can access other servers hardware information with now issue. When I publish the site to IIS running as ASP.Net 4.0 appPool because the site is written under the 4.0 framework, the hardware retrieval fails. (note: when I run the site and analyze the local machine hardware, it works perfectly... the problem lies in analyzing another machine on the network.)
My question is, What is the difference in permissions a site is running under when debugging in Visual Studio in comparison to a published site in IIS 7.5?
Things I've tried...
Changing the app pool identity to every possible built in option, and my own domain profile, which is local admin on the machine I'm trying to retrieve hardware info about.
Changing the user that access the file directory of the website.
Changing app pools period. (The site has to run under .net 4.0, or else it barks out bad things).
I'm thinking I may need to install the site directly on the server that's being analyzed, but I find it odd that I can get all the data from other machine when I'm debugging. Any insight someone could bring would be greatly appreciated. Thanks!!
This answer is, in some cases, you have to add the appPool identity running the site to the "Performance Monitoring" group for the local machine in order to allow an ASP.NET site access the server's local hardware resources...
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.