Pros and cons of editing sharepoint master page in sharepoint designer or visual studio? Which one do you prefer
SharePoint Designer
Pro:
WYSIWYG editing
Very fast turaround Edit/save/test
Con:
No Version control
Cumbersome reuse/deployment
(Download/Upload)
Visual Studio
Pro:
Integration with Source Control
Deployment/Reuse via Feature/Solution framework
Con:
Pure source code editing
Cumbersome Edit/Deploy/Test cycle
SharePoint Designer & Visual Studio
My recommendation is to use SharePoint Designer to develop the master page on your development machine. Then save the MasterPage into a Visual Studio solution for deployment to Test/Production:
Pro:
WYSIWYG editing
Very fast turaround Edit/save/test
Integration with Source Control
Deployment/Reuse via Feature/Solution framework
Con:
You need both tools, but SharePoint designer is free and this is in general the most efficient way of developing for SharePoint. Make what you can using SPD and the Web UI, then save it into a Visual Studio Solution for version control/deployment
For the most part I agree with what Per Jakobsen answered above. ESPECIALLY for SharePoint 2007.
Additional comments on the Pros/Cons of SharePoint Designer 2010:
I have actually had very good experiences with using SharePoint Designer exclusively for most of the "front end" work. Meaning, anything that is not a Server Side Web Part...
Regarding the "Cons" listed above:
Source Control -
Setting up the SharePoint Version Controls for the document libraries that store the web pages you are working on does a fairly decent job of managing Source Control - which is handy when you are doing development work on the Production server. (see below)
Cumbersome reuse/deployment
Not sure what is being referred to here, but I THINK it is in regards to developing code in one place, and then deploying that to a production server.
With permissions set correctly users are not impacted by development work because they will see the pages/code that is checked in, approved and viewable.
While I would normally hesitate to operate on production directly, there are many scenarios with SharePoint that require this - especially if you are editing XSLT data directly, etc. (what comes to mind off the top of my head are references to List or Library GUIDs and other "variables" that will be different between servers)
Cheers!
Although I don't know why, SPD also changes your <%# Register ... %> tags: it strips any leading "~" from the src="~/_controltemplates/..." attribute. You need to manually add them back in before publishing.
Related
Could someone point out the differences between Sharepoint Designer and the new Design Manager within Sharepoint 2013 ? I searched on the web but haven't found a concrete answer.
Thanks !
1) SPD can still be used to edit SharePoint pages, but the visual Design view and Split view were removed so you need to do all your editing in a code view. You can also still use it for the other things you mentioned.
2) Design Manager is free and included with SharePoint Server. It only works on Publishing sites so its not included with Foundation.
3) Its part of the base installation of the product. You don't need to do anything to procure it.
4) Not really. Design manager provides functionality for Importing/Exporting HTML and CSS that can be edited in any Web Design platform. For example Dream Weaver. Since SPD no longer has a WYSIWYG editor there is not real connection between the two.
5) Most of the customization you've already done will be brought across when you do a content database upgrade. I'm sure there will be some things that need to be upgraded after you do the database attach.
Will we be able to add .NET code blocks to a page in SharePoint 365 - the cloud version of SharePoint? If so, how do we allow code blocks in the web.config?
Will we be able to use SharePoint designer to customize forms and create dataviews with external datasources?
Can we have asp.net codebehind files and class references? (I suspect not)
.NET code blocks (server-side scripts) are not supported in Office 365. You should build your ASPX page purely from controls and web parts, which would contain the code. Solutions for the SharePoint Online share their restrictions with sandboxed solutions for SharePoint 2010. The solution scope is a site collection; not a web application and thus you cannot access the web.config. However, you may not need to; you're bound only to a single site collection and the most usual task - adding SafeControls - is supported, although the SharePoint engine does not use web.config to maintain them. You can see an example of deploying a web part.
You can use the Designer to customize pages, forms and views. External data sources (entity types) - BCS - were added to SharePoint Online by the end of the last year. I haven't checked what connector types are supported; I presume SQL and WS sources, at least.
You cannot have the code-behind in ASPX pages. There is no ASP.NET compilation of pages and user controls available; that's why you have to compose your pages of coded controls and web parts only. However, there is a trick to circumvent this - the Visual Web Part. The original visual web part could not be used in a sandboxed solution because it relied on the ASP.NET compilation. There is a template available in Visual Studio 2010 SharePoint Power Tools that packages pre-compiled code to the solution and is friendly to the sandbox.
You can develop and test your sandboxed solutions on your local SharePoint 2010 prior deploying them to the SharePoint Online. Although I was surprised that deployng a solution to the SharePoint Online was kind of faster than to my local farm :-) MSVS makes the development really comfortable.
--- Ferda
Not being a .NET developer, here is my limited knowledge. Office 365 is a multi-tenant implementation of SharePoint and you you should have the following capabilities:
upload code blocks as sandboxed solutions
ability to customize forms and data views with SharePoint Designer
Note that Office 365 offers 30 day trials that would allow you to test drive it. Let me know if you need more details as there are a couple caveats to be aware of when you start a trial.
This question relates to how to implement what Mr Prantl suggested.
Where to write C# code for office365 sharepoint site
Hope this helps.
I'm a developer with 5 years of MCMS development and without a single know how with SharePoint.
I want to use the CMS capabilities of Sharepoint to migrate my applications but I DONT KNOW HOW TO START!!!!!!
In my actual projects i have a Visual Studio solution with all my code, my templates and my usercontrols...
I cannot see how can i do the same thing with Sharepoint :(
I want to customise my site like i did before, i want to create pages based on templates like i did before.
Anyone knows where i can find a walkthrough that explains me that?
Thank U All.
Unfortunately I think you are going to have to learn SharePoint. Even the WCM features are a big topic, and probably the best book is Andrew Connell's "SharePoint 2007 Web Content Management Development" - I don't think a 2010 version is available yet. The good news is that I think the MCMS product had a big influence on how the SharePoint WCM features were architected, so the underlying principles will be similar.
SharePoint 2010 has a Visual Web Part that will encapsulate a user control which might make the transition easier. Also see my answer to this question about converting an ASP.NET site to SharePoint which might have some relevant information.
Most of the information about converting from MCMS to SharePoint is for the 2007 version of the product. This two-part article on MSDN seems to be the best starting point.
I cannot see how can i do the same thing with Sharepoint :( I want to customise my site like i did before, i want to create pages based on templates like i did before.
Problem is, SharePoint is not MCMS, no matter how Microsoft tries to brand it as its successor.
Creating sites in SharePoint is almost opposite of how things we were done in MCMS were you build from the ground up using ASPX templates, user controls and placeholders. In SharePoint, you'll have to strip out most of the OOB stuff you don't need. The recommended approach to custom development is through web parts, CAML, and the SharePoint APIs.
I'm using Visual Studio 2010 to develop a SharePoint Server 2010 solution. Part of this includes custom Page Layouts, but when editing them, intellisense is completely broken, since Visual Studio doesn't appear to know how to handle them. Here's what I've done:
Created a new blank solution
Right-clicked on the solution and created a new "Empty SharePoint Project"
Right-clicked on the project and created a new "Module"
Renamed sample.txt to MyPageLayout.aspx or created a new ASPX Web Form
At this point, intellisense for the new Page Layout is broken. It gets even worse with tools like ReSharper installed. Also, things like "Format Document" will break the Page Layout (by for example changing asp:Content to asp:content)
What I've tried to get intellisense working:
Added a Web.config from a standard Web Application Project to the root of the SharePoint Project - made no difference.
Added the ProjectGuid for a Web Application Project to the SharePoint project file - broke the project.
Is there any way to get intellisense, and the rest of the support Visual Studio can offer for Web Forms, available when developing SharePoint 2010 Page Layouts?
I have followed your post to some extent.
Using VS2010 (On an x64 machine)
Create a blank SharePoint solution. (this properly combines your #1 & #2)
Add a module (in SharePoint a module is like a folder or resource container)
added a new class to the module (intellisense present)
Added a new webpart to the module (intellisense present)
added a user control to the project designer works and (intellisense present)
I believe that you should consider creating true server or visual web parts. This will have a harder learning curve but will pay with dividends in the future. You will be able to package and deploy your solution again or to another server/farm. Aspx pages can be added and manipulated by the dreaded SharePoint designer. In 2010 the theory is that those designer mods can be packaged and deployed.
I work in this environment every day and the best advice I can give is to embrace the SP object model and do 'it' the sharepoint way. Don't try to force SP to be something its not. :)
This is probably not the solution you are looking for but it's the best thing I found for SharePoint development.
In your solution, create 2 projects :
1 SharePoint Project (empty or not)
1 ASP.NET web application project
Develop all your UI (aspx pages, ascx controls, etc.) in your ASP.NET project and create post-build steps that will copy the pages and controls to the appropriate folders in your SharePoint solution.
That way, you will benefit from all the features of web development in visual studio and it will be very easy to deploy as well. It is a bit of a time investment at first, but it is well worth it if you have any considerable amount of logic to implement in your aspx pages.
This blog post documents what you need to do.
you can add an intellsense to pagelayouts by closing the page and simply reopen it from
file->openfile->your file page layout path
Or you can directly "Right Click" on the file you want to open from the Solution explorer and then select "Open" : you'll get the Intellisense !
Basically need to use SharePoint (because we promote MS yay!) as a content management system for an internet facing site.
How do I get rid of the default SharePoint look and feel and make it look like however I want it to?
I know the process involves creating a new masterpage with SharePoint Designer. However I prefer to code webpages rather than use a visual editor. Is this possible? Do I need knowledge of .NET?
Just check out ferrari.com for a very well made redesign of a SharePoint site.
Heather Solomon's Branding SharePoint series would be a good place to start. There's a lot you can do just with CSS, JS and HTML, but the most complete solutions (like Ferrari) require some pretty extensive customization with .NET and other SharePoint development techniques (features and delegate controls, in particular).
Your branding effort will be a lot easier if you only need to heavily brand the public-facing "publishing pages", from which you can remove most of the SharePoint-specific elements that make branding difficult.
Also, SharePoint Designer has a source view if you don't like the visual editor.
Yes it is possible to make it look like however you want it to (as you've seen from the Ferrari site). However to create that sort of site takes a lot of work.
Microsoft recommend the use of SharePoint Designer for 'designing' pages and layouts. However changing their behaviour almost always needs Visual Studio and development in .NET. You can largely avoid SharePoint Designer (which may worth considering as it can be a PITA) with an open source tool such as SPVisualDev. Use this with WSPBuilder for packaging your solutions (and avoid VSeWSS where possible).
Considering it sounds like you're just getting started, be aware this is a big topic with a reasonable learning curve. Read a good book on the topic such as Professional SharePoint 2007 Web Content Management Development: Building Publishing Sites with Office SharePoint Server 2007 by Andrew Connell. It takes you through most things you will encounter from the ground up.
I'm working my way through Real World Branding by Andrew Connell at the moment. It seems like a good demonstration, with code.
Plus the Heather Solomon articles as suggested by dahlbyk are always informative.
Just changing the theme, or creating a custom theme for the site, can go a long way towards making SharePoint look a lot better. It's also a lot less intensive then changing the master pages.
How to create a theme
How to deploy a theme
Example customization you can do with just CSS
Does the EULA allow you to disguise the fact that it's MS software?
Remember, you didn't buy the software, you're just paying for the privilege of using it.