our team is looking to use a code generation tool for the current sharepoint application we are working on. We want to be able to generate most of the stored procedures and business entities instead of having to write them from scratch. Any recommendation what is the best code generation tool to use with sharepoint projects. I am familiar with CodeSmith, but I wasn't sure if there are any better solutions out there for this.
Code generation is not really necessary for SharePoint, all the code is generated in the SharePoint .NET Libraries.
The formulation of your question implies quite serious misunderstandings about SharePoint and it's use of databases.
If you want to talk to a custom database through a generated Data Access Layer, I would say go for the ADO.NET Entity Framework (works with VS2008 SP1 and .NET 3.5 SP1 only though.
A custom solution would be LLBLGen Pro
Related
We have different business divisions and each division has its ecommerce site hosted as webpart in SharePoint 2007. We also have product/adv images/documents in SharePoint.
We want to migrate from SharePoint 2007 to SharePoint 2013 and as per our initial research we noted that we must first migrate to SharePoint 2010 and then to SharePoint 2013
Questions :
what is the best way to migrate from sharepoint 2007 to sharepoint 2013 considering above context. please provide pointers..
or should we re-write our webpart code in mvc and get rid of SharePoint. since we have soa arch i belive it would not be big pain to do so.. just ui webparts will be replace with mvc site
which third party migration tools can be used considering their reliability and cost.
please suggest best way to go ahead.
As you mentioned, there's not direct migration path from 2007 to 2013. It's hard to give a definitive answer without knowing more about your environment, it really comes down to trying to estimate the cost and time doing a manual migration (2007-->2010-->) versus purchasing a tool.
I have one customer that used Metalogix to go from 2007 to 2013 and it was fairly successful. They had a couple of branding issues and some code that had to be re-written to use updated API's but considering the scope of the migration, it was fairly smooth.
Ditching SharePoint and re-writing everything using MVC.... Not sure about that one. Even though you have a SOA architecture in place, it doesn't mean it will replace everything that SharePoint provides. It does a lot of things; security, service app scalability, branding, ECM, BCS, search, etc.
UI issue may be faced as below
Migration HTML content (in content webpart) from ntext data type to XML data.
SharePoint adds some extra tags for xml validation and it distorts to whole UI for all the pages. Means look and feel will not be as it is after migration.
Table based old structure in menus and drop-dwon is very hard to manage. It must be in and Box model for better UI management.
I had used Metalogix in my migration projects and it worked 70% fine, however be ready for the post deployment fixes as you might have to rewrite some scripts. But overall it works fairly good. I would also suggest you to run a report before migration using SPCAF tool.
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.
We have an ASP.NET website that we use internally to do some project tracking and various work. We would like to integrate some pieces of it to co-exist with Sharepoint2007 WSS.
Basically what we would really need to do is be able to add items to a list in one of the Sharepoint sites.
I'm not sure where to begin. I've looked online a bit but it seems overly complicated. Is there a quick start guide somewhere that can get me rolling with ease?
The SharePoint Web Services would be a logical place to start. In my opinion this would be the easiest way to build interaction between ASP.NET and SharePoint.
A list of available web services can be found on MSDN.
If adding items to a list is the primary goal, then check out the UpdateListItems method of the Lists web service.
With the scope narrowed to Web Services, you can certainly find tutorials/references online. However, this InfoQ post by Trent Swanson is a decent introduction to SP web services. Note that they recommend generating .NET types using XSD files; in practice, for simple projects I have simply parsed the XML myself using LINQ. You can make it as easy or complex as you like, I suppose.
This is an architectural question.
We are in the process of building a document management site with basic workflow which needs to be external facing.The external facing application needs to be branded and should have the capability to upload and download documents and also support versioning.We have decided to use WSS 3.0 as the collaboration tool as it has all the features we need.We are planning to support multiple clients with custom branding for each client.
My question is should we expose WSS to the client for external facing or build a standard ASP.NET application using WSS in the application tier and let the ASP.NET app interact with WSS using the WSS API/Web service.This makes it easy to customize the ASP.NET application without having to make any changes to the WSS.The internal users doesnt need any branding and hence could go to the internal facing WSS site to do workflow activities. Building features and getting to brand has been a challenge since I started WSS development.
Please let me know your thoughts.
SharePoint is big. Really big. As a result, if you plan to develop a home-brewed middle layer between your customers and SharePoint, be prepared to do a lot of work unless you plan only to expose a tiny piece of the SharePoint interface.
I recommend exposing WSS, and building your application within, instead of adjacent to, the WSS framework by creating Web Parts, pages, and lists that meet the requirements SharePoint alone cannot. This should reduce your workload to something manageable.
Take a look at tools such as VSeWSS or WSPBuilder to ease your WSS 3.0 development (should you use Visual Studio), and take advantage of SharePoint Designer where it is appropriate.
If you don't know a lot about SharePoint, creating and exposing a UI is going to be difficult. Can you do it? Absolutely. Should you do it? That depends on your requirements, and your level of expertise with SharePoint. In my opinion, the easiest path would be to create an ASP.NET application and have that interface with SharePoint, but I spend 90% of my day working with ASP.NET and only do SharePoint development about once a year.
In my experience, if you have to ask whether or not you should build a new product etc. with some tool, the answer is generally know. If I can't answer it myself with maybe some looking around on the tool, I try not to use it on a major project, because that means, that I don't know it well enough to get myself out of bind when something unexpected arises.
If you do a custom coat over WSS underneath, you are essentially writing code that already comes with the platform, especially with SharePoint. I assume that price is a factor in your decision making or you would not use WSS alone. In that case it can be tempting to leverage WSS as a code layer, but I would expect that it would be extremely difficult to make that work smoothly.
Depending on your business model I would look at what hosted SharePoint solutions can do, especially if you can host a custom SharePoint site definition on their platform.
It would take a very strong IP or financial requirement to make me consider wrapping asp.net over top of WSS.
I have worked with a solution that does that and it does work for our externally facing site, but it is a maintenance 'mare.
I went to the Microsoft Visual Studio 2010 launch event in Minneapolis yesterday and was slightly surprised by how much they were trotting out SharePoint and improved SharePoint development in Visual Studio 2010.
SharePoint is something I've largely ignored over the years as a web developer and solution architect on a small development team. I was always under the impression that SharePoint was used mostly for intranets in large corporations, and that if you were developing for SharePoint, it meant that a corporate decision had been made to use it and you as a developer probably had few (if any) options.
I realize this assumption is probably incorrect. So, what are the "cool" uses for SharePoint? What unique business problems have you solved using it? What could make a developer excited to be working on something for SharePoint?
Document libraries in a Microsoft environment. There are many nice out-of-the-box features for managing documents.
Intranet sites that have permissions setup in such a way to allow business entities to control use of the site within their group.
Project requirements lists. List in SharePoint can be customized to some degree without ever programming.
As a conclusion so far, SharePoint is a blessing and a curse. It has a lot of value-adds, though anything outside that box is difficult change, but there are indeed many 'hooks' to do just that. WSS3.0 is free for Windows Server 2003, as is SP 2010 Foundation for Server 2008, so you can get quite a bit out of that without upgrading to MOSS or 2010 equivalent.
It's probably best used in intranet/extranet scenario's, true. There's many public facing internet sites built on it as well, if you find that cool :)
See http://www.topsharepoint.com/ (I built one of the top-10 sites ;)
It's definately not the best web content management platform but it is not bad and companies like people who have learned to manage their intranet to be able to seamlessly do the same for the internet site.
Personally I find it "cool" that I can deliver functionality quickly and without building the world from scratch (I've built enough document management solutionettes and prefer not to do it ever again). But if I have to custom build there's many footholds for customization and all of the .NET platform is available. There's workflow solutions that allow business users to customize their own workflows and not bug me with them. I'm sure there's plenty of other solutions out there that can do something similar but the integration with Microsoft Office and the rest of the Microsoft world is quite good IMHO.
I don't understand the antagonism against SharePoint and find it's mostly fueled by ignorance and people trying to use the platform for something it wasn't meant to do (like being a relational database). You will have to learn it; it's not like adding ELMAH to your project, it's a really big layer in your architecture.