I am starting work on a SharePoint 2010 Project and using the Visual Studio 2010 Built-In Magical Extension to do so. However, the turn-about cycle to re-deploy the solution is terribly long (build, package, retract, deploy, then restart, etc.) The only changes during this time have been to the individual Web Parts.
In the past I have used WSP Builder and for minor updates on the dev box just using the Copy-to-GAC/Copy-to-Hive features which has a much shorter turn-about to see changes to a Web Part. I was wondering if there was a similar (or alternative) method to get a similar quick turn-about in VS2010? The Mapped Folders address say, a changing view, but it's the Web Parts that interest me most now.
Please, if you are going to say "but you should always re-deploy", please do so only as a suggestion with other [useful] advice -- the testing servers get a full re-deploy. This is simply about helping me reduce the development cycle times.
Copy to 14 / Copy to GAC functionality in Visual Studio 2010
If you deploy the BIN directory rather than the GAC then you can just do a copy on postbuild - no restart/deploy etc needed.
Related
So, I'm about to embark on a fairly lengthy, time consuming project that could net me some good results/rewards - and I'd like to give everything the attention and focus it deserves. I will be the sole developer, and I'm experienced in that capacity (about 13 years in the industry). I've just never had to be responsible for EVERY choice so I'd like to throw this out there for some feedback. This is going to be a website.
Dev Tools on Win x64 workstation:
VS2010
SourceGear Client
FileZilla
UltraEdit
SQL 2008 Mgmt Studio
I will have my own DB Server machine also, which will run SQL 2008 for both the web DB and will host the Soucegear repository DB.
I'd like to have an automated build process that includes
pulling the latest code from the repository
checking it against rules (ala FX Cop)
compile the code
running a series of tests against the new compilation (unit tests?)
Any suggestion on tools to do these tasks? Should I just write & execute scripts to do certain steps?
Backups! - I'd like the source code repository and web files, graphics, media, etc. for the site backed up regularly. I use Mozy for my own personal backups - is there something more suitable for this kind of backup? Windows Home Server or something like that perhaps?
Lastly - what am I not thinking of that needs to be on my radar? For example, I plan on using jQuery but only have limited experience with it - any good javascript tools besides VS2010? How to most web devs test their sites across the plethora of browsers available? Should I use minify-ing tools for the web content - which are best? I've built plenty of web sites & applications before - this is just my first real "commercial" venture and I'd like it be founded in solid practices.
I, too, am a single developer and use much the same tools as you...
Couple of things...OK...it grew to more than a couple...
I like to use UltraEdit sometimes for editing my javascript files...as it has some features that VS2008 lacks...not sure abt VS2010...mainly a function list to aid in navigation of the file.
I also use JavaScript Lint to check the syntax of my javascript files...you can integrate it into UltraEdit...my choice...or VS...or both.
I use subversion for source code control...Visual SVN for the server and Tortoise for the client...both free
For backup I recently started using DropBox...you can point DropBox to the folder that holds your files and it will sync whenever DropBox starts (and it will keep the files synched on multiple machines...so if you have an offsite machine...you're covered if something happens at your main development site).
If you'll be using LINQ at all...I'd recommend getting a copy of LinqPad It's free, but you can pay to get "intellisense"...the examples included are fantastic learning tools.
When using jQuery...look for plug-ins that do what you're looking for...
I would be interested to hear how people develop for moss.
We currently use virtual environments, with wspbuilder and nant scripts to build and deploy.
We are finding the debugging and deployment process slow for our devs.
Can anyone suggest ways to speed everything up?
What you're doing already is great. I'd look at it from the hardware perspective: RAM and hard disk.
SharePoint, Visual Studio and SQL Server (if on the same box) all like to gobble up as much RAM as possible. Make sure you're running with at least 2GB, if not 4GB.
Also, Scott Gu says to get the fastest possible hard-drive. SSDs are a great way to get significantly improved performance. It's a little tricky balancing the cost with drive size at the moment however.
The only way i know of is just attaching to the w3wp process. It is the only way I think. I have added some external tools shortcuts for deploying faster on my dev machine, but that's it.
STSDEV!
Long gone are the days of manually copying assemblies to the GAC, deploying features, and syncing changes to the 12 hive.
STSDEV will create a new visual studio solution for your project which will include build configurations that automate the tedious process of deploying a solution.
There is a 'rootfiles' folder in the solution. This is where you add all files that you usually copy straight to the 12 hive. When you deploy, all of these files will be moved to their corresponding folders. (you match the folder structure within 'rootfiles' to the corresponding directories in the 12 hive).
It is all much simpler to use than it may sound. There's a few really good tutorials on the codeplex site, and after that, you should be good to go.
As far as debugging goes, once the deployment process is streamlined via the use of STSDEV, attaching to the w3wp.exe process to test code then redeploying is easy.
I feel like I need a better defined framework for updating my SharePoint (MOSS 2007) application with custom code changes. I am creating wsp solution files with features and new types and such, but once those get tested and deployed, I feel like it's a bit of a leap of faith, and that makes me nervous and occasionally reluctant to deploy changes. After deployment, it's difficult to correlate the current state of the SharePoint application with the specific code that is deployed on that SharePoint server. What features are actually installed and on which sites? Which features are activated or deactivated? Which version of this custom field or content type is really there? Things like this. If an error crops up, I have to rely on my assumptions about what code is there and actually running, or I have to spend time digging through deployed assemblies and the 12 hive -- not impossible, but pretty unpleasant.
What steps should I take to improve my ability to unambiguously determine the state of the application and find the code that truly represents that state? Are there third-party tools that can help with this?
I feel your pain... Application Developyment Lifecycle with SharePoint 2007 leaves me with a bitter taste in my mouth.
To answer your question. We built our own deployment utility that does a few things for us.
Checks state of key Timer Jobs (too many times we would do a deployment to find one WFE that did not get deployment)
Checks state of key Services on all our web front ends (again we want to know health of farm before we start kicking off timer jobs).
Shows file version and date of selected assemblies from GAC (does this across all Web Front Ends). We have seen problems before where assemblies did not get installed correctly across the farms.
Updates web.config settings based on an custom XML scheme we provide. We ran into some problems with web.config updates so we have thought about creating a utility to validate the web.config (specifically make sure there are no duplicate entries for specific keys).
Push content type updates (first time content types are deployed via feature it works great, but as soon as you need to update that content type it gets tough).
Checks status of WSP package after deployment or upgrade.
This utility uses the SharePoint API to do most of this work. Some of it is done by checking WMI Events.
Unfortunately the SharePoint development experience is lacking in this regard. As long as you are "namespacing" all features deployed using solution packages, you can use solution management from central admin to keep track of versions, and what gets deployed to which site collection.
Features are scoped from all levels from the farm to an individual web; so maintenence from that level is a little tough. I just try to organize all deployed code from the (top down) solution level.
It gets even more complicated when deploying custom timer jobs, event handlers, etc; I really hope that version next will address a lot of these common developer concerns.
Isn't the only way that you have a planned/controlled deployment process and a version management system like TFS
In the current project I am involved in we have:
Continuous builds
Daily Builds on a development server
When we release something to test we merge the code to the Main bransch in the version management system (TFS)
When tested and ready for production then we merge the main bransch to the release bransch
Using this structured way we always knows what is deployed in what environment and can also track all changes based on environment or changes in requirements(are also tracked in TFS)
We are starting with Sharepoint development with a team of three and are currently setting up our development environments. We would like to avoid installing a Server 2008 for each developer, thus a single terminal server has been setup, using Remote Windows to start a VS2008 instance on each developer's machine. Now we would like to separate developers' testing environments (i.e. a different site colletion per developer), but have realized that the assemblies would need to be installed into GAC to show properly on the site. But since there is AFAIK only one GAC, developers wouldn't be able to test their stuff independently.
Is there any way we could create separate testing environments without installing a bunch of 2008 Servers?
So you're all going to remote in an fire up Visual Studio and be compiling stuff and restarting IIS, etc?
You're going to be stamping on each other's toes.
A wiser choice nowadays is to use Hyper-V (or some other virtualisation).
We use Windows Server 2008 on our laptops, and use Hyper-V to run our dev environments. We then have a dev environment (sandbox) each, and these have VS2008, SVN, Nunit, etc.
Our code is tested against each other thanks to CruiseControl on the only shared Hyper-V.
This has been great for us... we distribute the load, we can work on the move, we don't step on each others toes and if we need to do a demo we can switch Hyper-Vs and demo from the demo Hyper-V (branched from the dev one early on so that the environments are known).
Go virtual and don't look back.
PS: I've just seen your comment about one server... just put Hyper-V on that and run 3 instances. That's also what we do ;)
I don't know about installing the server on everything, but this sounds like an ideal task for Virtual Machines rather than physical ones- where I work we using VMWare a whole lot for this kind of work and it does very well.
It's also useful to be able to roll back to a snapshot when it comes to testing installation processes and so on.
No. In addition to the GAC there are all the SharePoint files in the 12 hive, such as features and site templates. It's not worth what you save on server costs.
(Of course if you don't use the GAC, but deploy to the bin folder, and you don't touch anything in the 12 hive, you can give each developer their own web application on the same server. But this approach puts a lot of restrictions on what they can do. It's still not worth it.)
Virtual machines will work, but they can be slow to develop on. For instance, you'll need to restart the application pool for every GAC deploy - which means a pause of maybe 15-60 seconds to reload the application, (depending on the hardware). This will become annoying.
Virtual machines work better for test and production, where you don't restart the application so often.
I recommend a physical server for each developer. This will minimize the code-deploy-test cycle time, and make sure they don't have to worry about stepping on each others toes.
You are on the wrong track with Terminal Services - its just not going to give you any separation.
A lot of people do recommend developing on W003/2008 server directly, and it does simplify some things like remote debugging.
I prefer the more traditional method of using VMWare to run virtual machines. These can be running on a local or remote host. Remote debugging is a little more complex to setup but still possible.
Finally - if possible then deploy to the bin dir rather than the GAC. This will make it much easier to deploy automatically after compilation.
The contributors are right that there are lots of stumbling blocks to multi-developer single server environments.
Number one developers will be trying to attach to the same Web Application process w2ps.exe so creating separate Web Applications on different ports is a must unless you are prepared to share time debugging. How to setup a development environment for sharepoint 2013
The second problem is when you try to collaborate and use shared components/features. Having a desire to work separately is debatable, I believe that the team developers should be collaborating and sharing so combing work is desirable to ensure seamless integration into a single final solution and that no work is duplicated. The multi-developer single server environment works perfectly until you try to collaborate 'One common mistake is to have one “development server” used by all team developers. Unless team members are working on totally unrelated components and never need to do common things such as restart IIS or attach a debugger to an IIS process, this type of environment generally doesn’t work well.' http://technet.microsoft.com/en-us/magazine/dn145990.aspx We made this mistake through lack of experience and knowledge, but once you make it it's possible to work round it.
My first attempt to share features was to copy developer 1's project into developer 2's solution and add a reference to it in developer’s 2's project and add all the features to developer 2's package. Deploying this works fine for developer 2, until as I discovered if developer 1 detaches their solution from the debugger it retracts the solution based on the duplicated solution id from the farm and therefore from each developer's web application. Therefore developer 2 has the rug pulled out from underneath them. Although this is a part solution and seemed to work for a while, it took me a while to work out what was happening and what combinations of dev 1 and 2 deployments make each other’s work and not work.
So I found a better solution. Under the project properties in Visual Studio under SharePoint tab there is a combo box called 'Auto-retract after debugging'. This by default retracts the solution when the developer stops the attached debugger and pulls the features out from underneath the other developers. Unticking this box prevents the retract and leaves each developers individual solutions deployed at farm level and on reattaching to the debugger just replaces the solution with minimal fuss.
In my experience recycling the IIS application pool is so fast other developers don't even notice, but with a larger team than 2 this might become more prevalent, so perhaps someone else could add their experiences. I also guess unless the other develops try to attach at exactly the same time that the recycle is happening it'll be fine, so is a really small chance of having a cross over time, and simply detaching and reattaching will fix this if it is ever experienced.
Can anyone suggest the best deployment approach for VSeWSS 1.2 based development?
I have been working with this for more than 6 months now.. has anyone tried using WSPBuilder for this purpose?
I Personally prefer using stsdev (http://www.codeplex.com/stsdev). I've used both WSPbuilder and STSDEV. Stsdev offers some development project templates that you create using an stsdev gui, not like the standard project templates you create using new > project.
The stsdev projects has got a Rootfiles folder, which corresponds to the '12 hive' on the destination server. All the files you put into Rootfiles folder and subfolders, is automatically added to solutionpackage.ddf and manifest.xml, so you dont have to worry about editing these files and compiling them using makecab.
Another great thing that stsdev offers is build targets, like build, deploy, redeploy, Refresh Assembly in GAC, retract and upgrade. So stsdev projects automatically compiles the binaries, builds the .wsp package, and runs the stsadm commands according to the build type. You can customise the behavior of the build targets if you like, by editing the Microsoft.SharePoint.targets located in the DeploymentFiles folder of the project. As long as you are only working on the code, Refresh Assembly in GAC is a very fast build method, and you can see the changes in sharepoint immediately after.
An disadvantage of stsdev is if you use source control, the manifest.xml and SolutionPackage.ddf if not checked out, are read only, and will result in a compile error (i usually check out all the files in DeploymentFiles folder when working on a project). So you have to check out these files before building. Another thing is that it takes all the files under the Rootfiles, including the hidden vssver2.scc files if you are using source control. The project still builds and deploys without problems, but the files are in the wsp package, and copied to the '12 hive' on the destination server.
I think that compared to WSPbuilder, stsdev lets you customize just about anything of the development project, which i haven't been able to do in WSPbuilder.
You should do yourself a favor and look at VSeWSS 1.3. See Kirk Evans' blog for a good video overview: http://blogs.msdn.com/kaevans/archive/2009/03/13/sharepoint-developer-series-part-1-introducing-vsewss-1-3.aspx.
Major downside could be that it requires Visual Studio 2008.
I have been a STSDEV advocate, but am now leaning towards VSeWSS 1.3. My suspicion is that other WSPBuilder and STSDEV users will feel the same over time, but I haven't finished my evaluation of it yet.
We have always used WSPBuilder. This is best if you are looking to create wsp's.
It also provides a VS Add-in. You can build, deploy, upgrade etc. right from VS. Provides VS templates like Blank features, Web Part Feature, Feature with Receiver, Workflow feature, Event Handler, Item Template etc...
We manage 20+ projects with WSPBuilder
As Kirk Liemohn points out, you really should upgrade to VSeWSS 1.3. We took lots of customer feedback and there's lots of new features for developers in this version.
It includes quick deploy commands for deploying just the new binary or just the files into the SharePoint 12 folder structure. It also runs on x64 OS with Visual Studio 2008. It has command line support.
Available here
I prefer WSPBuilder as well. I don't have any problem with not being able to configure WSPBuilder the way I want it. In the latest version you can override its settings for each project or developer individually should you want to.
There is also a great add-on to WSPBuilder called SPVisualDev (codeplex.com/spvisualdev). Among other features it provides templates for adding ASCX files and it automatically pushes down files you have put in your project 12-hive folder from VS into the real 12-hive folder.. A huge time saver for me.
One downside to VSeWSS 1.2 was the lack of deploy to bin support. 1.3 adds that, but I haven't gotten it to work with referenced assemblies.
I've switched to STSDev 2008, a spinoff of the original STSDev with bug fixes. I've been working with the main contributors to add documentation to the project on CodePlex, but it's had 1900 downloads in little over a year.
I have used VSeWSS 1.2 and 1.3 and it does make deployment pretty easy. The question I had was, what do you guys usually do if you wanted to distribute the Web Parts to a customer administered SharePoint server.
Do you just take the Release folder and tell them to run the setup.bat script? Do you package it differently? Do you create custom installers?
VSeWSS 1.3 CTP is out now, and does have command-line support. That being said, the extensions are IMHO--and based on currently using them for a very large, very complex project--a pain in the rectum for the following reasons:
Every time you open a solution of extensions-enabled projects, you will have to sit and wait while the VSeWSS wheedles through each and every project, checking structure and trying to repackage each solution. The wait seems to grow exponentially with every extensions-enabled project you add to the solution. Given all of the waiting already included in doing SharePoint development inside a VM, the wait can be excruciating.
While VSeWSS is making its way through the projects, no indication is given of any work going on; VS simply becomes unresponsive.
Every time you close your VS solution with extensions-enabled projects, VSeWSS does the whole operation over again. Given that, by this time on my current project I'm usually 10 or so hours in the seat, and the last thing I want to do is wait longer to go home, this process is worse that excruciating (if that's even possible.) Most of the devs on our team just go to Task Manager and kill the devenv.exe. process rather than waiting.
We've had a very bad time of it trying to use the current (CTP) version of the extensions to do an integrated build. We've been having a number of problems using VSeWSS from the command line to do build and packaging of all of our projects.
In brief, use STSDEV. Setting up the folders is kind of a pain, but once you have everything scripted out, you're pretty much set.