SharePoint Developers … what are your tools and environments like?

Something I take great interest in and spend a bunch of time thinking about are SharePoint Developers.  I was one before I moved up here to Redmond and joined the SharePoint product team.  Of course that means I hold a dear place in my heart for all you pro developers out there who are stuggling with the lack of developer tools targeted at the hard core SharePoint developer.  Dont worry ... we hear ya!!!

Something I have been doing recently is quizzing other sharepoint developers out there about their development practices, tools and environments they use in their jobs.  Now i want to take that to anyone (is there anyone?) reading this blog.

So here are my questions for you:

- What does your development environment look like?  Do you develop in a VPC (what products are installed) or on a dedicated machine?  Does your team use a single SQL server? or do you each run your own?  Do you run standalone MOSS/WSS installs? or are they connected to a Farm with other developers machines connected?

- What are the tools you use and how do you use them?  Do you only use Visual Studio?  or do you use a mix of VS and SharePoint Designer?  Do you have a bunch of scripts or batches for things yout cant do in Visual Studio ... like package up your Features into Solution files etc... Do you use any third party tools?

- If you use source control what do you store in it?  Do you just store your Feature files & code? or do you store scripts to automate a build and upload content to it etc...?  Is this all integrated with Source Control?

- Do you use any tools to help you build Feature & Solution files etc...? or do you manually write them?

- Have you looked at the Visual Studio Extensions for Windows SharePoint Services?  if so .. 1.1? or just 1.0?  What do you think is missing from that tool that you have to do using manual steps or scripts you built etc... (for more info see:

- What sort of applications are you building?  one off sites? or templates etc... for many sites?

- Do you sell the things you build many times?  or are they usually one offs?

So many questions I know 🙂  I want to make sure we stay focussed on delivering the tools that make the most sense to you the developers.  That is why I think it is important that you get to have your say about what direction we are should head in.  So go ahead ... make my day ... and add your comments below. (your comments might take a while to show up as i have comment moderation on to stop all the spam ... but i will approve when i can). Also ...I am totally happy for people to reply anonomously if they like.


Chris Johnson

Comments (25)

  1. James says:

    VPCs right now, with Office 2k7, MOSS & SQL installed.

  2. Sean McLellan says:

    Exclusively under a VPC, running Windows Server 2003. Visual Studio 2005. Differencing disks turned on for a quick rebuild of the environment. We build on our own VPC’s running MOSS, do an integration on a separate server to validate milestones. MOSS is usually a full install but only server in the farm (all necessary services are turned on within that single server, running SQL Server Dev on the same VPC) Usually have the POP3 server installed to test e-mail notification within the VPC.

    Last project we used VSeWSS. 1.1 CTP and VSS 2005 source control (Added the PKG folder to source control so all the features/solution files are added) Desperately wish there was a final verson of VSeWSS and one for VS2008 as VSeWSS 1.1 CTP definitely has it’s quirks.

    Last project was a SharePoint solution, project previous to that was a one-off site, but still needed content types/web parts/etc within source control.

    At this point VSeWSS is workable, but like I said, it definitely has it’s quirks. If I had 100 dollars to spend on SharePoint tools at this moment I’d place

    50 on improved SP Documentation (ever try to add a navbar navigation node to an audience programmatically? Forget MSDN, just google that sucker… don’t ask what the 4 Semi-colons are as the value for the property)

    25 on Debugging/trace tools,

    25 on VSeWSS (Cause it really is a time-saver, just needs to be finished, tweaked a bit (build solution without deploy, add blank features, VS2008 support, better source control support (constant updating of the manifext.xml file is irritating)

  3. We use custom built pre-installed VPC’s with:

    – SQL Server 2005

    – MOSS 2007

    – Visual Studio 2005 SP1 + Workflow Extensions

    – Office 2007

    – SharePoint Designer

    – DNS

    – A lot of tools (Reflector, EventhandlerExplorer, SharePointManagement)

    All run locally because we sometimes have to work without an internet connection. VPC is 10 GB in size.

    The only main problem in this way of work is the VPC is slow, very slow. Any syggestions on speeding it up will be greatly appreciated.

  4. David Marsh says:

    Here are my answers:

    – What does your development environment look like?  Do you develop in a VPC (what products are installed) or on a dedicated machine?  Does your team use a single SQL server? or do you each run your own?  Do you run standalone MOSS/WSS installs? or are they connected to a Farm with other developers machines connected?

    My development environments run on VMware Workstation 6.0.

    I have two main VM’s that I use for development and just make copies of these or use VMware snapshots for different projects.

    All our team works like this.

    We also have a central dedicated SQL, AD, MOSS and WSS on 4 separate boxes for a staging/deployment/test environment.

    Both VM’s are both running everything in a single machine environment.

    They have the following software with the latest service packs for all the software listed.

    Windows Server 2003 Enterprise

    SQL Server 2005

    Visual Studio Team Suite 2005

    Team Foundation Explorer

    Visual Studio Extensions for WSS 1.1 CTP

    SharePoint Designer 2007

    Office Professional 2007

    U2U CAML Query Builder for quickly validating and generating CAML queries. I just pick any list, it is usually just so I can get the CAML query, although I have found that using SharePoint Designer to insert a DataView Web Part of any list and then applying a filter will produce the CAML query I need in the properties of the Web Part.

    FastStone Capture for screenshots for building "As-Built" documentation.

    – What are the tools you use and how do you use them?  Do you only use Visual Studio?  or do you use a mix of VS and SharePoint Designer?  Do you have a bunch of scripts or batches for things yout cant do in Visual Studio … like package up your Features into Solution files etc… Do you use any third party tools?

    Mostly use Visual Studio for development and SharePoint Designer for master pages, page layouts and Data View Web Parts. Custom made batch files that install Solutions and Features and one to retract and remove everything. I just cut and paste this now from one project to the next. I use the VSeWSS for quickly building out a web part or event receiver etc and build using F5 but will eventually move DLL’s over to a custom project that has the Solution and Feature XML files etc and the batch files for building and deploying the code. No third party tools. They just complicate the number of moving parts and things to install and maintain in the VM’s. Haven’t seen any that don’t get in the way of what you are trying to do.

    – If you use source control what do you store in it?  Do you just store your Feature files & code? or do you store scripts to automate a build and upload content to it etc…?  Is this all integrated with Source Control?

    We use Team Foundation Server and try to keep everything that makes sense in a Visual Studio project and anything built in SHarePoint Designer is manually copied out into VS and checked into Team Foundation Server.

    – Do you use any tools to help you build Feature & Solution files etc…? or do you manually write them?

    Manually write them and sometimes use the ones built by VSeWSS as a starting point.

    – Have you looked at the Visual Studio Extensions for Windows SharePoint Services?  if so .. 1.1? or just 1.0?  What do you think is missing from that tool that you have to do using manual steps or scripts you built etc… (for more info see:

    – What sort of applications are you building?  one off sites? or templates etc… for many sites?

    Clients vary, a mixture of one off applications and others with customised templates to be used repeatedly.

    – Do you sell the things you build many times?  or are they usually one offs?

    Mostly one offs. We reuse custom built web parts to get efficiencies in future projects but don’t go the extra mile of selling them independently. We build SharePoint environments that tackle the Information Architecture, Governance, People and Cultural issues of the organisation and not just the technology piece.

    What I think is missing is an overall tool that brings together all the different artefacts that are built into a single view that can then be managed and deployed from a central location. Also a modelling tool that allows me to build what I can through the UI and produce the code that will work like it does when I build it through the UI without having to build site definitions. Site Definitions are scary areas to visit in SharePoint and none of the ASP.NET developers in my team will go near them. I don’t like to because it is a world of pain with no huge benefits. A tool that sits on top of all the XML goo in SharePoint and allows me to model the SharePoint objects in Visio/DSL type environment would be great. This is so I can easily deploy my site template. Too many things get left out of STP files.

    Being able to save Data View Web Parts into VS or build them in VS without causing customised pages would be great to. Always difficult to deploy these things.

    I think that is enough for now.

  5. Mid-size organization IT architect says:


    One of our initial surprise what to discover that ideally, each developer should have its own WSS/MOSS installation. Our costs were highly impacted; we have some MSDN licences but not enough to cover the number of developers in the WSS/MOSS space. So we try to accomodate all of them by sharing a VPC with all the problems/issues that come with it. Ideally, Microsoft should have a special licensing packaging for a WSS/MOSS developer that would not require and MSDN licence; I’m sure it would be a success and I would surely buy it (e.g. a pre-configured VPC containing W2K3 + WSS/MOSS as stand-alone mode).

    We are currently using a set of VPCs (usually one per project/scope using one/many Site Collections) to support our development and they’re all hosted on the same physical W2K3 server. This causes a lot of problem especialliy on the I/O side given the unexpected size of the VHD files. Also, since more than one developer may be working on the same project, they often affect each other (during debugging, DLLs conflict since they’re using the same GAC, etc.). It would be a great idea if the architecture of WSS and/or .NET would allow to isolate WSS/MOSS-based DLLs at Site Collection level (e.g., like a sub-directory within the GAC to allow some level of isolation).

    On each of these VPCs, we’ure using stand-alone WSS/MOSS installation with embedded SQL, VS Studio 2005 Pro, and VSS to manage source code. VSS is using a single repository that is shared across all the VPCs. We are using the extensions for WSS and also for Worklfow Foundation. Once the code is unit tested, it is migrated to a small farm (one WFE/APPL and one DB Server) another set of shared VPC (one per logical environment such as DEVL and SYST) that are hosted on another physical W2K3 server; all databases are also on a second W2K3 server with SQL 2005 Server since our volume testing is performed there. Our current production farm is 2 WFEs, 1 APPL (SSP/Search) and 2 DB Servers (clustered).

    We are developing almost every type of WSS/MOSS artefacts – Event Handlers, Custom Pages, Web Services, Features and custom workflows with custom ASPX (no use of InfoPath forms). Everything is for internal use and most of the time, it is specific to a Site Collection/Business Unit. We are written some common classes that are shared across projects (e.g., wrapper classes for some of the SP API classes, Data Access layer instead of BDC to connect with legacy, etc.).

    As much as possible, everything is wrapped as a Feature. We are not using Solutions for now but that’s the next step for us given that our production environment is a Farm and Solution will greatly ease the deployment process. We also have a bunch of scripts/batch files to perform migration from logicial/physical environment to another; these one are not integrated in VSS.

    We will revisit our development environment and our directions are: Put Visual Studio on the physical PC of the developer instead of putting it on the VPC; keep the WSS/MOSS stack on a VPC running on the physical PC of the developer. Use Solutions as much as possible to ease migration, upgrade and deployment. Increase of usage of VS Extensions to ease deployment (Post-Build events, etc.) and building of WSS such as Content Types, Site Columns, etc., using templates.

    WSS/MOSS development is a huge learning process due to several factors: It is relatively new, the Microsoft documentation is not really useful even if it’s improving over time but when we had started, it was almost scary; thanks to the strong WSS/MOSS community; most of our findings and learning come from blogs and books and without it, it would have been very difficult.

    Even if my idea of a pre-configured WSS/MOSS VPC will not make it as a product, I still think that Microsoft can use this medium as an evalutation VHD. It could also be a very good medium to show how the various tools (VS Extensions, etc.) and techniques (Features, Solutions, etc.) can be used to optimize the development and deployment process.

  6. chjohn says:

    WOW…. what a great response so far!  This is really valuable stuff.  It is really interesting to read what the various techniques are the different people are using in lieu of great tools.  I will be sifting through the replys and using this for a couple of things:

    – for input into some posts i would like to make over christmas on custom code development on SharePoint.

    – for input into some efforts we are working on here to better guide developers on how to get started with SharePoint development.

    I will follow up with a post with my comments and summary of the conversation here once the replys have slowed and i have had time to dig through them all.

  7. bittercoder says:

    What does your development environment look like?

    => WK2SERVER VMWARE images ->  WSS + SQL SERVER 2005 Dev Ed. + VS2005 SP1 + SharePoint Designer + VseWSS 1.0 (Running on VMWare Desktop edition, to support higher monitor resolutions and better snapshot support)

    => We have three "stock" images… one with just WSS 3.0, one with WSS 3.0 + Nintex Workflow 2007 and one with just MOSS 2007.  The images dont have Office installed on them (we tend to do this depending on the current Office environment the client has, and if the developer needs those tools or not)

    Do you develop in a VPC (what products are installed) or on a dedicated machine?  

    => VPC, but on a fairly high spec development machine (4gig of ram, quad core) – mostly to counteract poor VM performance (I allocate the VM 2gig of ram) .. I think the fast Desktop PC can pay for itself within a single month considering how much time I was wasting twiddling thumbs while developing in a VPC on my laptop.

    Does your team use a single SQL server, or do you each run your own?

    => Each on our own – we like to keep our development environment portable, so we can take snapshots.

    Do you run standalone MOSS/WSS installs? or are they connected to a Farm with other developers machines connected?

    => Stand alone.

    What are the tools you use and how do you use them?

    => WPSBuilder – used to create our WSP’s

    => SharePoint Installer – distributed with the WSP to our clients.

    => CAML.Net – used for some query requirements.

    => NUnit, RhinoMocks & TestDrive.Net – unit testing.

    => Reflector.Net (I’m not sure how you can develop for SharePoint without it ;o)

    => Some other Misc tools for VS.Net i.e. GuidAddin, GhostDoc etc.

    Do you only use Visual Studio?

    => Yes.

    Do you use SharePoint Designer?

    => In the past I’ve tried – but we haven’t found a good way to integrate it with our source control and automated deployments.

    Do you have a bunch of scripts or batches for things yout cant do in Visual Studio?

    => We have batch files for repetative tasks i.e. creating/remove test sites, installations in live environment etc. is done via the SharePoint installer.

    Do you use any third party tools?

    => Nintex workflow 2007 has been used in the past, as part of a clients requirements to deliver declarative workflows.

    If you use source control what do you store in it?

    => Subversion with Tortoise SVN

    Do you just store your Feature files & code?

    => Yes, though we also store builds from the build server.

    Do you store scripts to automate a build and upload content to it etc…?

    => Yes.

    Is this all integrated with Source Control?

    => Yes, with a partial use of Continuous Integration i.e. automated WSP Builds, but not automated deployment to test/staging servers yet.

    Do you use any tools to help you build Feature & Solution files etc…?

    => Yes, WSPBuilder.

    Do you manually write them (xml)?

    => Largely, sometimes we use a temporary VseWSS 1.0/1.1 project to generate xml fragments, providing a starting point.

    Have you looked at the Visual Studio Extensions for Windows SharePoint Services?  

    If so, VseWss 1.1?

    => I looked at 1.1 but for the last project it was released too late for us to attempt to use it (we’d already ditched out of VseWss 1.0 in frustration and adopted WSPBuilder)

    VseWss 1.0?

    => Yes, it was too limited for what we need to do – couldn’t tweak the feature etc. xml as required.  But we did use it to "code-gen" stubs for feature recievers etc.

    What sort of applications are you building?  

    – One off sites?

    – Templates etc… for many sites?

    => Both, but the templates have only been for deployment within a single organisation (domain-specific)

    What do you think is missing from that tool that you have to do using manual steps or scripts you built etc…

    => The ability to access / override any generated fragments of XML … to be honest I’ve found the WSPBuilder experience to be easier then VseWSS, it seemed easier to version control, merge etc. and the microsoft documentation aligned with our project structure better.

    Do you sell the things you build many times? or are they usually one offs?

    => One offs… strictly bespoke SharePoint work.

    Hope that helps!


    – Alex

  8. Tom Clarkson says:

    One of my main responsibilities recently has been putting together a really good development environment for a team creating the various components necessary for a 10,000 user intranet.

    Each developer has a standalone virtual PC, with an additional server for integration.  So far we have been using Visual Studio 2005 on images customised by each developer, but in the next week or so we will all start using a standard image with Visual Studio 2008.

    We do all development in Visual Studio. SharePoint Designer is useful for prototyping, but can’t be used in production so any files produced get packaged as features.

    For creating features and solution packages we use WSPBuilder combined with some Visual  Studio extensions (templates, an MSBuild task and an add-in) that I developed myself. It took a bit of work to get up and running, but the end result is a development process that just works. I’m planning to release the tools in the near future.

    We have source control for the project files, though it isn’t as easy to use as it could be – developing on VPCs means we aren’t allowed to connect our development environments to the network. Hopefully we’ll have a workaround for that soon.

    I looked at both versions of VSEWSS and wasn’t impressed -I think the problem is basically that it tries to hide the complexities of the 12 hive with a simple abstraction that turns out to be both more complex and less functional.

  9. jsiegmund says:

    – I’m running Virtual PC 2007 with a virtual image for SharePoint development on my own laptop. Other developers use there own laptops, they’re not connected apart from source control.

    – I’m using the entire scala; Visual Studio with extensions, SharePoint Designer, the Office/WSS SDK’s and all tools included. Every piece of software seems to have it’s own goal and purpose, there’s not really one cool solution integrating everything you need (though VS could be that I think). As for SharePoint designer, for some reason I don’t like that tool. Seems very slow and does funny things when you don’t want it to 🙂 I was wondering if, for instance, the Experience Web suite could become helpfull?

    – We use Source Control from a third party (SourceGear) which works wonderfully well. Only source code is upped, nothing apart from that.

    – No tools apart from the default VS extensions and SDK tools.

    – I’m using the 1.0 extensions, didn’t notice 1.1 untill now. Thanks, I"ll definitely look into that.

    – We’re building mainly web parts and site templates. I’m also working on some BDC enabled sites, no real technical challenges until now, but I do expect some. We’re still quite new to the whole SharePoint experience, and we’re just starting to roll out some environment at customers.

  10. jsiegmund says:

    Oh and I forgot.. I just started a topic at MSDN about virtualised production servers. If someone has anything on that, please leave it here:

  11. Trent Zhu says:

    I set up dev environment for developers, but I am not a developer, so I will try my best to answer as many questions.

    Our SharePoint DEV environment: Developers do coding on their "own" desktop machine, debug on their "own" VPC, deploy to "Shared" internal DEV servers.

    1. Developer’s individual machine

      Windows XP SP2, Visual Studio 2005 Pro SP1, SQL Server 2005 Dev SP2,  Office Pro 2007, SharePoint Designer, Visual Studio extension for WSS, tools like WSPBuilder, EventhandlerExplorer, etc.

    2. VPC that is hosted on each developer’s desktop:

      Windows Server 2003 SP1 (DC +DNS), MOSS 2007, SQL Server 2005 SP2, Visual Studio 2005 SP2

    3. Internal DEV Server 1 (MOSS)

      Windows Server 2003 SP1 , MOSS 2007

    4. Internal DEV Server 2 (WSS only)

      Windows Server 2003 SP1 , WSS 3.0

    5. Internal DEV Server 3 & 4 (load balanced server farm)

    6. Internal Database Server

       Windows Server 2003 SP1 , SQL Server 2005 SP2

    We use Visual Source Safe 6.0 for source control, we just store Feature files and code.

  12. Pete says:

    – What does your development environment look like?

    Always a VPC with MOSS, VS 2005 SP1 and SharePoint Designer installed (occasionally other Office products as required). Where possible, have a single SQL Server on another VPC. Usually working alone (projects aren’t big enough for a team). Deploy to load balanced farm for testing then to live.

    – What are the tools you use and how do you use them?

    Visual Studio for everything except master pages, page layouts and some prototyping using SP Designer. No real need for scripts. Also use Reflector and would like to use Resharper if it didn’t take so much RAM.

    – If you use source control what do you store in it?

    SourceSafe which is horrible but not my choice. Store everything related to the project (inc. features and documentation) in there.

    – Do you use any tools to help you build Feature & Solution files etc…? or do you manually write them?

    Manually write. Have looked at VSE for WSS 1.0 but it sometimes behaved strangely and didn’t give me enough control/visibility.

    – What sort of applications are you building?  one off sites? or templates etc… for many sites?

    One off, all bespoke.

    Pain points for me are:

    – The API documentation is sketchy or missing. I logged a support call about a problem with an API method and was told MS wouldn’t support its use because it hadn’t been documented – unacceptable as so many methods *aren’t* documented!

    – Debugging is slow and laborious (partly the speed of my dev environment and partly because it just is), also timeouts can be annoying.

    – SP Designer isn’t the most robust application, also when I export master pages and page layouts it has a tendency to include SP Designer ‘stuff’ so I always use Master Page Gallery.

    – Unit testing.

    Thanks for asking for feedback!

  13. Aaron POwell says:

    Windows 2k3 running on MS Virtual Server 2005 R2 as the host OS

    MOSS 2007

    Seperate SQL 2005 server as we’ve found the performance to degrade massively if the SQL server is on the same machine

    Visual Studio 2008 RTM (previously VS2005 SP1) with TFS 2005 as source control (but soon to migrate to TFS 2008)

    Feature creating is manual (bar content types and field types which use Andrew Connell’s STSADM extensions)

    Solution creation is done through custom software I have written myself as I wasn’t a fan of any existing ones I found.

    I try to avoid SharePoint Designer where I can, I find it very buggy (for some reason my navigation pane no longer works), particularly with checking out file’s. More than once has a file been listed as checked-out when its not, or not checked out when it is.

    I also find it often slow (particularly if you switch between design/ split/ code views) and confusing to use.

    If a plugin existed for Visual Studio I would love it and ditch SharePoint Designer all together.

    I’ve used the 1.0 extensions, wasn’t aware of the 1.1. Do they support VS2008? Otherwise they are not of any use to me.

    I use the DotNet Reflector a lot to follow what SharePoint is doing under the hood so I can resolve my issues, or implement similar functionality

  14. SharePoint Manager 2007 (in full object view mode) is a lifesaver for reverse engineering and quick and dirty live modifications:

  15. CodeJedi.NET says:

    Chris Johnson from the SharePoint product team wants to hear from the SharePoint developers.  This

  16. Annie says:

    Currently 1-man-band

    Dev. Box

    – Win XP!!!!!!!!!

    – VS 2005 (of course no VSeWSS) + WSS SDK + Workflow for VS

    – SPDesigner

    Test/Demo WSS Box

    – Win2003

    – AD

    – WSS 3.0

    – SharePoint Tips Untity Pack

    – Event Handlers Explorer

    – Self-written Backup/Restore tools. (This is the safest bet to deploy a site as one-off.)

    – VS 2005 w/ VSeWSS (Not much use, do not like to write programs on a server box)

    – Access by Remote desktop

    I am trying to avoid workflow. Use event handler as much as I can. (The logic of event handler is easier to be understood by sharepoint devlopment beginners.)

  17. aconnell says:

    I live in the virtual world… specifically MSFT VPC 2007 but primarily VMWare Workstation for performance and snapshots. As far as tools go, it’s a mix of Visual Studio and SharePoint Designer. I use a custom MSBuild target + makecab.exe with a small tweak to my project file to generate the WSP’s on every single build of my project. As for building Features and Solutions, aside from using the WSS.XSD for IntelliSense, I use special templates I built for DevExpress’ CodeRush (think "active" snippets)… more here: Sure, it is a commercial product, but for $250, I can build SharePoint "solutions" (not WSPs) significantly faster resulting in much more efficient work output and deliverables.

    As for the Visual Studio extensions for WSS (VSeWSS), I won’t go near them with a 100′ pole or recommend them to anyone. Tried v1 as well as the v1.1 CTP and neither impresses me… in fact they cause more issues than not. As they stand today, <IMHO>they are a very bad thing for people to use and lengthen the development of solutions, not to mention cause many problems (always regenerating GUIDs? ouch)</IMHO>. I for one will hold out to see what the VSTO guys do (ra ra Paul!) 🙂

    Oh… and can’t say enough about Lutz’s Reflector. Still as handy today as it was in the DF & beta days!

  18. Karthik says:

    This was helpful! I am looking for a road map to building source control structure for a MOSS app, how do the folders look like, how will they correspond with 12 hive for deployment and things like that..

    Any ideas?


  19. Memmorium says:

         Good idea!

    P.S. A U realy girl?

  20. tim says:

    Well there is something called sharepoint DSL toolkit – 2 part screencast is on youtube

    looks like addon to visual studio

  21. ravindere says:


    We are Planning to set up MOSS Project. Can any one help me what can we store in MOSS Source control and what can we store in TFS Source Control?

  22. moss1 says:

    Yes, using VPC with SQL Server Express, VS2005 with SP1, SharePoint Designer with SP, and WSS 3.0.  Also, using WSP extensions for VS2005 to create solution projects.  

    It is easier to work on standalone machines to create feature solutions and then deploy them to farm environments.

  23. AndyG says:

    The potential for MOSS with my organization is huge!  But good tools to enable developers like myself is just MIA.  What is desparately needed is a developer edition for MOSS.  Without that, I am afraid MOSS will never really achieve its capabilities where I work.

  24. Jignesh Patel says:


     I am currently looking into options for our internet and intranet site development for my company and wondering if I will be able to use the aspx pages I developed for website into a sharepoint site? if yes, can i also use the master pages that I used in my site into new sharepoint site?

     Also, can you tell me if this page (this blog page where you have this article) is actually website page or a sharepoint website page?

     Thanks for the graeat article, anyways.



Skip to main content