We are a group of four students who have to develop SharePoint web parts for a certain project. After two weeks of trying out various options, the only possible way we could do it was to set up a Windows Server 2008 R2 64-bit virtual machine (using VMware Player) on a Windows 7 Professional 64-bit desktop with an i3 540 (because it supports VT, unlike the laptops we four have), make four user accounts on the VM OS, and remote desktop into it from our laptops to develop. The VM has Visual Studio 2010 Ultimate, SharePoint Foundation 2010 and SharePoint SDKs installed.
My question is; if we create four different projects in Visual Studio, can we concurrently use that single installation of Visual Studio from remote desktop to work on our individual projects?
If yes, what kind of problems should we expect and how can we ensure we don't run into them?
Alternatively, is there another more trouble-free way of working this out (like changing some setting in Visual Studio to allow multiple instances, etc.)?
Thanks!
While this should work without issues, I would take care with an issue like this.
I would first verify that this is allowed under your current licensing for Visual Studio. I suspect that this is likely a violation of the license agreement, and as such, I would take care with trying to find a better solution. It may be allowed under your license (as there are many different forms of licensing), but I would check this very carefully prior to operating in this manner.
That being said, I suspect this will work fine. Visual Studio does take care to work and store settings per user account, so there is likely no issue. Microsoft Support would be the proper channel for support if you do run into any problems while operating, however.
If your laptops are 64-bit, I would install Visual Studio 2010 and SharePoint 2010 on each of your laptops. If your laptops are 32-bit, I would create 4 separate virtual servers.
Beyond the licensing that Reed points out, I would be concerned about resource sharing. During a SharePoint 2007 project, we had 3 developers sharing a single SharePoint virtual server with Visual Studio 2008 installed on each of our laptops. Everything went fine for awhile until development got really heavy. As soon as one developer would finish running a deployment job, another would start one. The application pool was down so often that the web sites were unusable. Everything was fine once we each got our own virtual server.
If you really must use one server (not recommended), then i would suggest you create 4 seperate web applications. This means they will each get a seperate application pool. Then each users should still be able to debug their webparts without effecting the other users. The debugger should only "break" the application pool that the user is on.
Related
Management wants us to start using Visual Studio through Xenapp when we are working remotely. I can't find any good documents about how teams are using this. The biggest issue seems to be managing workspaces. Most development can be done without a connection using TDD but getting the latest versions is a problem. The Xenapp version of VS doesn't recognize the workspace on the local machine. You can create a workspace to the virtual desktop but then you would need to develop in the virtual machine. If you do map the the virtual environment to the local it gets all files again. This is a problem as that alone can take up to an hour.
We have 4 Xenapp servers that are load balanced so you never know which one you will end up on. If anyone is doing this I would appreciate any help.
I've spent waaaay too much time trying to figure this out. I'm running Windows 7 and Visual Studio 2010 in a VMware Fusion virtual.
When I debug my website project, Cassini (aka ASP.NET Web Development Server) starts and the site shows in my default browser (IE). I stop the debugger, make some tweaks to my C# code, and start the debugger again. The website starts up in IE and the site displays, but its using the code base from when I initially debugged NOT including any tweaks in code between the initial debug/build and subsequent debugs/builds.
The only way I can get code changes to build and run in the browser properly is if I manually stop the ASP.Net Web Development Server from the tray and then run debug.
Has anyone encountered this? Not sure if its caused by VS2010 or the environment being a virtual on a Mac.
Manually stopping Cassini after every debug is really starting to suck.
Thanks.
Check if Visual Studio is set to recompile the projects when there are changes.
Check that Tools > Options > Projects and solutions > Build and run > On run, when projects are out of date is set to Always build.
Perhaps you will have a more pleasant experience with IIS 7.5 Express as a replacement for Cassini.
From that page:
IIS Express is a lightweight,
self-contained version of IIS
optimized for developers. IIS Express
makes it easy to use the most current
version of IIS to develop and test
websites. It has all the core
capabilities of IIS 7 as well as
additional features designed to ease
-- website development including:
-- It doesn't run as a service or
require administrator user rights to
perform most tasks.
-- IIS Express works well with ASP.NET and PHP applications.
-- Multiple users of IIS Express can work independently on the same
computer.
Here's an article to help you get started.
Figured this out. I had mapped my Visual Studio 2010 folders to a VMware Fusion share in order to make my .NET projects accessible from Mac world (for copying graphics files into the projects, etc.). Evidently there was some type of permission issue or something that did not result in any sort of alert that was causing the problem.
I remapped all VS folders (Project, Website, etc.) into the standard Documents folder of my user instance and everything began working as expected.
Thanks for the help.
I'm trying to get started with building my own webparts, planning to follow this MSDN article.
I've downloaded Visual C# 2010 Express - I'm not quite at the point where I feel comfortable dropping 1000 big ones yet, and I installed Visual Web Developer 2010 Express via the WPInstaller.
Following through the tutorial, aside from the fact that I don't get the option to create a "Web Control Library", a gap I filled with this article, I can't seem to find the sn.exe tool (or the "Visual Studio 2005 Command Prompt"!).
I know it's not quite a direct programming related question, but I can't even get the thing going yet!
Any help is appreciated.
Thanks
EDIT:-
I think I may be jumping the gun quite considerably, I wrote a simple hello world example and tried to build it but it doesn't have any references to the Microsoft.SharePoint packages and they don't appear in my lists.
Am I understanding some more research I've done (namely this) correctly, in that I have to actually have a full installation of actual SharePoint on the machine I'm developing on?
sn.exe is part of the .Net Framework SDK tools - not actually part of Visual Studio.
If you've got the SDK installed (which I think you must have if you're using VS) then it will be in a directory such as (depending on which version of .NET SDK you've got installed)
c:\program files\microsoft.net\SDK\v2.0\Bin
You can develop SharePoint web parts with VS express but you won't be able to use extensions like VSeWSS which can make your life a little easier.
You don't have develop on a machine with SharePoint installed upon - you can just copy the Microsoft.SharePoint.dll assembly from a machine with it installed on and reference it in your project.
There are pros and cons to developing on a SharePoint machine.
Its easier to get started -
especially debugging locally rather
than remote debugging.
Harder to be
sure that you're code will work a
'real server' - are you sure you
don't have any dependencies that may
not be installed.
Harder to work with
multiple versions of SharePoint (2007
WSS and MOSS and 2010 foundation,
server etc).
If you do want to work with a locally installed SharePoint then
You can install windows server OS with SharePoint and Visual Studio.
there is a hack for installing SharePoint 2007 on vista (referenced in the SO article you link to)
you can install SharePoint Foundation 2010 on Windows 7 (but I am not sure what the licensing restrictions are - is this maybe something thats given through MSDN?)
If you decide to go with the remote server installation then save yourself some grief and use virtualization such as VMWare Server, Virtual PC or Hyper-V.
If you are doing SharePoint development trying to reference the Microsoft.SharePoint namespaces you need to have SharePoint installed on the machine if you want to do things like debugging, etc. For SP 2010 you CAN install SharePoint on a Win 7 machine. For previous versions of SharePoint, you will need to setup a Server that is Server 2003 or Server 2008 (you can't install SP 2007 and earlier on client machines). Generally this is a Virtual Machine for developers.
Having said all of that, there are relatively few reasons you need SharePoint to develop a WebPart. The vast majority of the WebPart functionality is part of the System.Web.UI.WebControls.WebParts namespace. Even if I am accessing SharePoint data, I generally use the ASP.NET web part.
If you are trying to use the new SharePoint VS 2010 functionality to create Visual Web Parts, etc, then you will need to install SP 2010, since that functionality is not supported in earlier version of SharePoint.
John
As the release date for the public beta of SharePoint 2010 is coming closer and closer, I'm wondering how to set up a developer machine for it. I've heard that for developing on SharePoint a 64 bit system is needed and that Microsoft advises to use Windows 7 64 bit and install SharePoint 2010 on it.
I think that won't be an option for me as I only have one computer here at work and I don't like to install SharePoint on the same machine that I use for my normal office work (email stuff, writing concept papers, ...).
Am I right that I only have two other options? Using Server 2008 as a desktop operating system and install SharePoint 2010 on a virtual machine or using Windows 7 64 and use VMWare to host the SharePoitn 2010.
So I'm wondering if there are any other options and which one you chose? What experiences have you already made?
If you decide to install 2010 on your Vista/Windows 7 machine, make sure you have at least 4GB of RAM (I'd personally want at least 6, if not 8), and follow the instructions from MSDN: "Setting Up the Development Environment for SharePoint Server"
Yes, you are right there are only three options:
Install SharePoint onto the OS natively (new for 2010 and aimed at developers)
Install SharePoint into a VM you run on your machine
Get a second machine and install SharePoint on it.
In addition you will need Visual Studio 2010 for the developer experience to be complete.
I would highly recommend trying the install native route as it will provide a great development experience and will run fairly light. Also at worst you can have two batch files, one of which starts and the other stops the services so there will be zero impact except disk.
I am doing some SP2010 development at the moment. I have:
Windows Server 2008 R2 Standard with Sharepoint 2010 and Visual Studio 2010 installed, running on Hyper-V. I just connect to it via Remote Desktop. Works a treat. I do all my dev in the VS2010 instance running on the VM, leaving my physical work computer free for everything else. I back up my work using TFS, so if I mess up the Sharepoint install (somehow), I can just roll back to a previous snapshot.
hope that helps. :D
Sharepoint 2010 development takes a lot of hardware resources. You can't use Hyper-V on Windows 7 but if you have the Enterprise version of the OS, you can build and boot directly from VHD, taking normal advantage of hardware resources. To learn how, you can visit this post: http://rambletech.wordpress.com/2011/09/19/boot-windows-7-directly-from-virtual-hard-disk-image/
HTH.
What are the best practices in setting up a new instance of TFS 2008 Workgroup edition?
Specifically, the constraints are as follows:
Must install on an existing Windows Server 2008 64 bit
TFS application layer is 32 bit only
Should I install SQL Server 2008, Sharepoint and the app layer in a virtual instance of Windows Server 2008 or 2003(I am already running Hyper-V) or split the layers with a database on the host OS and the app layer in a virtual machine?
Edit: Apparently, splitting the layers is not recommended
This is my recipe for installing TFS 2008 SP1.
There is no domain controller in this scenario, we are only a couple of users. If I was to do it again, I would consider changing our environement to use a active directory domain.
Host Server running Windows Server 2008 with 8GB RAM and quad processor
Fresh install of Windows Server 2008 32bit in a VM under Hyper-V
Install Application Server role with IIS
Install SQL Server 2008 Standard edition
Use a user account for Reporting Services and Analysis Services
Create a slipstreamed image of TFS 2008 with SP1 and install TFS
Install VSTS 2008
Install Team System Explorer
Install VSTS 2008 SP1
Install TFS Web Access Power tool
After installing everything, reports were not generated. Found this forum post that helped resolve the problem.
Open p://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx
Run the webservice (see above link for details), it will take a little while, the tfsWarehouse will be rebuilt
It is very important to do things in order, download the installation guide and follow it to the letter. I forgot to install the Team System Explorer until after installing SP1 and ventured into all sorts of problems. Installing SP1 once more fixed that.
One critical thing you has to keep in mind about TFS, is that it likes to have the machine all to it self. So if you have to create a separate instance on Hyper-V do it using the proven Windows Server 2003 platform with SQL Server 2005.
I am sure Microsoft has done a great job getting it to work under Windows Server 2008 and SQL Server 2008, however you don't get any additional features with this newer install and it is currently unproven in the wild.
So my recommendation is to stick with what is known until the next release of TFS comes out.
Also splitting the layers is definitely not recommended, especially in the workgroup edition where you will only be allowed to have 5 licensed users. Those 5 users will never exceed the server's needs. Also my recommendation is to not update Sharepoint if you don't need to. In my environment, we don't really use Sharepoint all that much, so I left it alone. Sharepoint is usually, in my experience, where most of the problems come from with TFS.
I just upgraded our team to TFS 2008, from TFS 2005. The hardest part was upgrading SharePoint 2.0 to 3.0, so I would make sure to do that first, if you have not already installed TFS 2008. We had a couple of other difficulties, but they were all either related to the SharePoint upgrade, or to the fact that we were using an aftermarket Policy package - Scrum for TeamSystem. We are on SQL Server 2005, so I cannot address SQL Server 2008. As for splitting the layers, we did not do this either, as we are running on Windows Server 2003 and everything ran under the host OS.
Splitting the layers is only needed for more than 450 users.
I would also recommend having the Build Server on a completely seperate machine. Building is very file system intensive. SQL Server performs best when it has complete control of a file system - so having build and TFS on the same machine may create performance issues while builds are executing.
Perhaps this can be alleviated with proper tuning and seperate physical drives - but I'd think in the long run it would be a lot simpler to just either use some old hardware - or spin up a small virtual machine on a seperate host for your builds