I had installed sharepoint 2013 foundation, sql server 2012 in Windows Server 2012 operating system in virtual machine.
I need to setup development environment for sharepoint 2013. Can any one help me on what I have to install apart from that.
I have some questions like
Where does the Visual studio 2012 has to be installed ( either in the client or in server VM)? What components I have to install? Do I need to Install Sharepoint Designer?
Kindly help me out on these.
Cheers!
here is how to Set up the development environment for SharePoint 2013 from Microsoft site
regarding other questions :
Mahmoud Farahat is right you have to install Visual Studio on the same machine that has SharePoint installed on it also to ensure all the SharePoint specific dlls are registered in the GAC.
From SP2013 Microsoft no longer allow installing SP on anything other than Windows 2012 and 2008R2. 2010 did let you install it on Windows 7 which I imagine is what your development locals are running as or at least some version of Windows desktop OS. You had to change a config setting to be able to do this, you can look this up but isn't relevant anymore as it can't be done. I've installed SP2010 on my local laptop and it takes a powerful machine and makes it run dreadfully for everything. Using the local machine for development in my opinion is just not practical as SharePoint is just so power hungry. I have had 2010 running as locally hosted VMs on Virtual Box and this work reasonably well so is a possibility for each developer to have a Virtual Machine locally. Our IT didn't like the idea of hosting servers on the corporate domain anywhere other than centrally, so wasn't an option for us, but if allowed in your policies then would work fine.
So our 2013 development environment which I setup is hosted on a powerful single server farm, i.e. App, Web & DB all on one virtual server (acceptable for dev). We are running multiple developer connections to a single SharePoint development server via Remote Desktop. Ensure you have multiple RDP sessions enabled in group policy, http://technet.microsoft.com/en-us/library/cc784146(v=ws.10).aspx. This server has SP2013, VS2012 and SPD installed on it oh and IIS8 (Windows 2012).
It's possible to both develop on the same Web Application (SharePoint speak for ISS application pools) but you can only debug one session at a time because devenv.exe (Visual Studio) attaches to the w3ps.exe (IIS application pool) to be able to deploy, install and activate each of your developed features (more SP talk). So once one developer has attached to the Web Application to debug anyone else will get an error that the process already had a debugger attached.
There are two solutions, take turns at debugging, this works but in even a small team of two (can't get any smaller) this is a big handicap and especially when launching the debugger can take a couple of minutes even on a powerful server. So what is the other option? Well you have to create a process for each developer to connect to individually. This relates to Web Applications in SharePoint. You can achieve all of this through Central Administration but if you have a number of developers doing this in the GUI can be a bit boring for an Administrator. So to achieve the same result via a script execute the following code in PowerShell:
Add-PsSnapin Microsoft.SharePoint.PowerShell
New-SPWebApplication -ApplicationPool "SharePoint – DEV1" -Name "SharePoint – DEV1" -ApplicationPoolAccount (Get-SPManagedAccount "yourdomain\service.account") -Port 81
New-SPWebApplication -ApplicationPool "SharePoint – DEV2" -Name "SharePoint – DEV2" -ApplicationPoolAccount (Get-SPManagedAccount "yourdomain\service.account") -Port 82
New-SPSite -Url http://yourspservername:81/sites/YourSiteName -Name YourProjectNameDev -Description "Developer1’s Development team site for Your Project" -OwnerAlias yourdomain\developer1.username -Template "STS#0"
New-SPSite -Url http:// yourspservername:82/sites/ YourSiteName -Name YourProjectNameDev -Description "Developer2’s Development team site for Your Project" -OwnerAlias yourdomain\developer2.username -Template "STS#0"
Remove-PsSnapin Microsoft.SharePoint.PowerShell
This assumes your using NTLM authentication and have a read through of http://technet.microsoft.com/en-us/library/ff607931.aspx to ensure you have the correct parameters specified for your environment for the command New-SPWebApplication. The code as is will also create a Content database with a guid suffix which you may not be as clear so specify if you want.
This creates a SiteCollection for each developer and a site based on Team Site template for each developer. Copy each line individual line for more developers.
We have kept the default created Web Collection on port 80 for the collaborative site where we deploy all our Features onto for a final combination testing.
Each developer needs to edit their Project properties in Visual Studio to have their Site URL properties match their individually assigned Port.
Be careful when combining the projects in your Source control as this property will be specified in the csproj file and each developer will post their own port number into the repository.
My original answer is valid and works and seems to be of use to some people. However, we quickly ran into difficulties with performance running even recently purchased enterprise servers running a VMWare virtual server. I think the main issue is Disk IO and deploying a solution would take 4 minutes +.
Originally our laptops weren't up to running a local VM of SP2013. If budget is available and having gone through a whole development cycle I would strongly advise to use Oracle VM Virtual Box and create an individual instance on each developer’s laptop. The catch to that is the shear spec of the hardware required. 16GB of RAM is a minimum and realistically a 512GB SSD is also needed although you might get away with a slightly smaller one. We had our laptops upgraded to meet this minimum and there aren't many laptop chassis out there capable of more at present.
So once you have the hardware, download VM Virtual Box and install it on the host. You'll have to create a single server farm and allocate 12GB of memory to the VM leaving a remaining 4GB for the host. Install Windows Server 2012 on the virtual server, probably downloaded via an MSDN subscription. You’ll have the ISO downloaded onto the host laptop hence the need for a big drive; this can be deleted after the install.
Setting up the Network settings for the VM is challenging and maybe different in your environment but I went for Bridged Adapter from the wired network port on the laptop through its dock. This means that the moment you take the laptop off the dock the VM will lose access to the internet. You can change to the Wi-Fi port but all your host file settings will be wrong. So be careful if you take the laptop to a pitch expecting it to work.
Depending upon how your Enterprise Admins respond to having random VMs on the corporate domain, you may need — as I did — to create your own domain. I had to use the SP server to do this and this isn't recommended by Microsoft, but it hasn't held me back. So I turned the SharePoint server into a Domain Controller and a DNS server as well. You'll need a DNS server if you want to develop SharePoint apps. This gave me full flexibility and control over the environment with no interference or waiting for others to do work for me. The only drawback is cross-domain authentication so you just have to get used to typing in fully qualified domain usernames and having two passwords and that single sign on won't work for testing from the local laptop. No major given what flexibility it gives you in exchange. So now you have a domain controller as well create the service accounts for SharePoint as well as an account for the developer. You'll now be able to run the install of SharePoint 2013 off of a mounted ISO probably again downloaded via MSDN subscription. Install Visual Studio 2012 and SharePoint Designer along with any source control tools you wish to use.
To be able to communicate across the host and the virtual server on the host’s host file C:\Windows\System32\drivers\etc\host add in a record for the server. This will let you access the server by its name. This has to be done because the host and the server are on different domains and the record of the server isn’t in the corporate DNS. Because the virtual box is set up as a bridged network and because our environment uses DHCP, rebooting the virtual machine can change the IP address of the box. Be careful if that’s the case you may need to change this periodically during the use of the box.
You may need to add some proxy settings to the server for the server to access the internet back through the corporate network via the bridged adapter. This will require the authentication credentials of the developer’s corporate domain account and not the one used on the server in the newly created domain. For instance I need to add proxy settings to Tortoise HG for the source control to be able to push commits up to bitbucket.org.
We found that, for a single user development setup, the laptop performs significantly better than the development server we created on our department’s server hardware. This is purely down to the performance of SSDs over even enterprise level SANs. Scaling that up to multiple users for a live environment would probably be the opposite but taking this approach definitely gave us a significant improvement in productivity bringing a code iteration down to half that of the original deployment time. You may even be able to clone environments across multiple developers' laptops just by copying the VM files.
© 2022 - 2024 — McMap. All rights reserved.