I have to build a faccing public site with his own visual identity with sharepoint 'on premise', have someone know some tutorial or online class about how to do this. Because didn't find anything clear about how to do this with sharepoint in my researches
Although I am not an SharePoint expert, I believe what you are asking is a loaded question that encompasses several topics of knowledge and technical hurdles you would have to learn or overcome. There are a lot of details missing from your request, so I can only offer you some topics you will need to be familiar with as I have not seen any single tutorial that shows what you are asking for. But you should be able to find tutorials on individual topics that would be relevant to your request:
Public Facing Site
Opening your on-premise SharePoint server to the public can be done by changing network settings which is a straight forward task for any network admin.
Best to use a domain (ex mysite.com). If you don't have one, you can purchase a domain. Then have it registered and configured to connect with your server(s),
Some other things to consider is security, firewalls, load balancing, DMZ zones and business policies.
Own Visual Identity (a custom look of SharePoint)
One method is to create a custom master page for SharePoint which can be done via Visual Studio or SharePoint Designer. This requires knowledge on web development such as CSS, HTML and possibly javascript. Developing a on-premise SharePoint environment with Visual Studio requires a lot (i mean alot) of setup and work.
Another method is to use the SharePoint theming engine to create custom themes.
You can also buy pre-built themes from other sources.
Final thoughts
Unless absolutely required, I would avoid using a on-premise SharePoint to host a public site as there are much more simpler and cost effective solutions out there. There is also SharePoint online which will probably provide most of what you need out of the box. Need to ask yourself what this public facing site will do and if SharePoint is the right product to use as I consider SharePoint complex and suited for specific needs. I worked with a on-premise SharePoint solution and it takes a crew of IT professionals and tons of money for maintenance and development.
Related
We need to select a CMS for our company's website which will allow the designers to make changes to the pages, add pages, view and publish them.
We r using Visual Studio 2010 for web development and includes Global.asax, Masterpages, User-/Custom-Controls, Security (FormsAuthentication, custom Membership-/RoleProvider). W ehave SQL server 2008 for the DB.
I have looked into various CMS like Sitefinity,N2CMS, Umbraco, DotNetnuke. We kinda liked playing with the demo of N2CMS. We don't want to start developing the site from scratch. We want to integrate some CMS into our application for the designers to use. However, I can't find any helpful documentation regarding the integration. Everyone starts talking building from sctrach. The documentation for N2CMS seems so outdated.
If anyone can guide me how to set a CMS into exsiting application, I will really appreciate it.
Thanks
I have a good amount of knowledge in the ASP.NET Webforms and MVC worlds. Shortly I will be tasked with implementing custom web applications with Sharepoint. I have great flexibility with this project (i.e - I can use custom web apps outside of Sharepoint if that's possible) but like most projects the most limiting factor I have to deal with is time.
Here are some questions that come to mind:
Can I easily integrate a custom MVC project into Sharepoint 2010? What are the pros and cons if I can?
Same as #1 only with Webforms.
If #1 and #2 are not viable solutions, can I easily create custom web applications within the Sharepoint world? What will the learning curve be with my background?
I understand developers can now use Windows 7 to deliver Sharepoint 2010 solutions. It looks like I can use a trial of Microsoft Sharepoint Foundations 2010. If that's correct, are there any development differences or gotchas I need to be aware of before digging into the Foundation version? I don't want to get up to speed on Foundation and then find out that the Server edition (the version that will be deployed) is vastly different.
Thanks!
SharePoint is based on webforms - it is relatively easy to add custom user controls and web parts, though if you want to use SharePoint data in a completely custom web app, especially mvc you will probably need to host it seperately - you can access everything you need through the SharePoint API, but it makes the deployment a lot more complicated.
The workarounds to get webforms mvc running in the SharePoint web app tend to involve stuff that would never get past corporate infrastructure people, but I've been getting good results with precompiled razor views set up based on http://razorengine.codeplex.com/ - my version that produces code which can be included in a SharePoint project is at https://github.com/tqc/RazorEngine
In the 2007 version there were significant architectural differences between WSS and MOSS. With 2010 there aren't as many differences, so you should be ok, but it would still be better to develop on the same version you are deploying to - download a trial of Standard or one of the demo VMs - If you do a lot of .net development, chances are you already have an appropriate dev license.
What are you trying to accomplish? Are you connecting your MVC site to SharePoint or are you building something "MVC" on top of the SharePoint server?
In any case, there is an MVC SharePoint project on Codeplex here http://sharepointmvc.codeplex.com/
Here is an article on the subject http://blogs.msdn.com/tom/archive/2009/03/17/asp-net-mvc-and-sharepoint.aspx
I havent touched it, and it seems a bit abandoned to me, but it might get you along.
Check out it outlines one method of running MVC with SharePoint
Generally, SharePoint will simplify many user-oriented requirements you may have - such as authentication, permissions control and personalised areas (with MySites).
If you go with SharePoint, you almost have to build your product for SharePoint Foundation so that you can keep your customers' total costs low (SharePoint CALs, SQL Server, hardware, etc). You'll want to build friendly user interfaces for managing permission, allowing your users to create their own pages, and other provisioning tasks -- or provide rock-solid documentation on how to do it out of the box with SharePoint. With SharePoint, you should use features and Web Parts to deploy your code either way , whether SaaS or on-premise. That will make it easier to deploy and upgrade.
We currently have a product that uses Sharepoint and a number different Web Part libraries to display realtime data to customers. The way this has been set up is that each customer has a custom login (Active Directory), a custom site with their specific data hooked up in the web parts. That means for every customer we have a completely separate site. Eg:
Customer 1 -> www.site.com/sites/customer1
Customer 2 -> www.site.com/sites/customer2
Customer X -> www.site.com/sites/customerX
As you can imagine, this is impossible to maintain as any small change that we make has to be manually propagated across all of the site, a task that has become impossible.
We are also developing separate ASP.NET MVC application that live on the same server under their own Virtual Directories Eg. www.site.com/App1/
I've been tasked with investigating how to best redesign the system to provide a more integrated and "application platform" type architecture.
Personally I would love to just ditch the Sharepoint as I think we are using it incorrectly (not as a CMS at all), but my manager wants to keep the Excel Services for customers who pay extra (a customising service).
We currently embed the MVC applications in Sharepoint using the Page Viewer Web Part, but this gives us less control over the layout of these applications
My next thought was to have a standard ASP.NET masterpage across all MVC sites and sharepoint so that they look the same, whilst still providing the functionality required, but investigation and testing seemed to be that Sharepoint master pages are horrible beasts that barely resemble a clean master page.
Basically I'm stumped, and I'm getting a little disheartened about Sharepoint and it's god awfullness.
Does anyone have any experience with this or could provide some ideas/tips?
Very much appreciated.
CodePlex - SharePointMVC
A helper project for hosting asp.mvc content inside SharePoint.
I want to build a custom document management web application that ties in with sharepoint for the actual document versioning and storage. I'm hoping for something like a sharepoint widget that I can plug into my web application that would allow me to tie in with sharepoint and download documents, make edits to them, and upload them back to sharepoint, with sharepoint handling all of the versioning and storage.
Basically I'm looking for a sharepoint API.
If WSS is the answer to this, are there licensing issues that I need to consider?
Thanks.
The best way forward is probably to use SharePoint's web services as that way your application can run on a server that doesn't have SharePoint installed.
Regarding Licensing, as long as you are licensed for Windows Server then WSS is free. However, depending on what database you use you may need to make sure that your users are licensed for SQL Server. Have a look at these links:
SharePoint Connections
Technet
Eggheadcafe
Wouldn't it be easier to do some development to customize SharePoint to your needs instead of just using it as a backend?
If it's SharePoint 2007 you're talking about, then on the server side you have the SharePoint API (Microsoft.SharePoint.dll) and on the client side, SP provides web services for manipulating lists, libraries, users and most other things you might need.
As Jeremy said, getting data to and from SharePoint through the Web Services, requires you to write CAML queries, but it's made easier by the help of tools such as this free CamlQueryBuilder
There's loads of documentation on both the API and the web services online.
If you're planning on using SharePoint 2010, all this will be quite easier, as more options are available for developers, e.g. API for the client side as well as the server side. Also new in 2010 is LINQ for SharePoint, which IMO really rocks!
Sharepoint is accessible with CAML Queries in that you can create, modify, and delete any object in Sharepoint with this.
You could create your own front end and just communicate to sharepoint.
As far as licensing, WSS comes with any Windows Server OS, so your client would just buy a license to the OS and be fine.
I'm looking to take advantage of SharePoint's document management features for an intranet portal. Portal users, find SharePoint rather cumbersome so I would like to build most of the site in ASP.NET, and integrate SharePoint document libraries so that i don't have to create a document management system.
How can I do this?
In my honest opinion it sounds like you are trying to reinvent the wheel. If users are finding it cumbersome it is generally do to lack of understanding or incorrect implementation and training.
However if you do want to integrate into SharePoint, you can reference the full SharePoint API Library. It is .Net based and allows you to access any aspect of SharePoint in code. You need to reference the Microsoft.SharePoint assembly to access these classes. You will need to setup a development environment for this, since you can't develop for SharePoint without having it installed. The detailed documentation on the namespace starts here
From personal experience we had much more success implement a solid SharePoint structure, with training, and also building the SharePoint portal the same way we would have built a website. Users now insist on having applications in SharePoint.
Basically, you can set up and administer your document library (or libraries) through the standard SharePoint pages, but you build your own ASP.NET site for users which will access the information in the document library. This site will use either the SharePoint object model or the SharePoint web services to retrieve, manipulate and store documents in your document libraries.
Generally the rule is that if you are deploying your ASP.NET site onto the same server as your SharePoint instance, then use the Object Model; if you are deploying to a separate web server, use the Web Services.
Some of the common issues for SharePoint development, and how to avoid them can be found here:
http://msdn.microsoft.com/en-us/library/bb687949.aspx
The “Working with Folders and Lists” section will be particularly relevant to what you are doing.
Use an IFrame :)
Seriously.. you'll have to work within the context of SharePoint or you will find yourself rebuilding SharePoint. This excludes building it as a regular ASP.NET app. But it is not that far off.
Why not adapt the way SharePoint works to how your users like to work? It was made to be changed and appended.. within limits.