views:

86

answers:

4

What are the compatibility issues someone has to take into account when migrating from .net 3.5 to sharepoint 2007 ?

I mean, libraries, COM objects, databases..

Specially about databases, it was sugested to me not to connect to a database directly, but an alternative wasn't said, so i guessed it should be better making this question about the differences to consider when building a sharepoint intranet portal based on an existing .net one.

+1  A: 

uhh, none. sharepoint webparts are .net Sharepoint maintains its own db, for lists, etc. if you need to access the Sharepoint database, you must use the Sharepoint object model--to do otherwise would be heresy.

you can access OTHER databases via whatever means you would like. Not really recommended, though.

Muad'Dib
A: 

Today, Sharepoint development is much like any regular ASP.NET development. You'll just need to deal with a new object set aka Microsoft.Sharepoint.

Some new concepts you probably will have to learn will be GAC deployment, strong names, SP* object disposal, manifest files and to develop a greater interior peace, just to do not make any permanent hardware damage when things go crazy (and they will).

You should stay away from content database as much you can. When you have no options left, you STILL should be away from that.

Rubens Farias
+2  A: 

If you're actually attempting to convert to SharePoint forms, lists, etc. than your data access is handled implicitly by SharePoint when you work with the classes in the Microsoft.Sharepoint library.

Your ASP.NET code (assuming it's not ASP.NET MVC) will operate in SharePoint but you don't want to call directly into any content DB that SharePoint created/manages/etc I'd imagine.

antik
Only if you intend to store your data in lists and libraries ... otherwise you do not have to move anything from LOB data. You can access it directly from code or from the BDC.
webwires
A: 

SharePoint is built on top of .NET so I'm not sure what migration issues you are refering to. SharePoint is a collaboration platform. That is where it's strength is. If you have databases and functionality that is used in business processes then you are still free to access that information in many of the same ways either through web parts, application pages or even completely custom pages. When they say do not access databases directly they are referring to data stored directly on SharePoint in lists and libraries or properties and settings related to SharePoint.

Aggregating LOB apps within SharePoint is actually one of it's strengths. One method of doing this is the BDC as long as the information is read only (Use custom forms or webparts to update the information through "Actions").

webwires