I am new to SharePoint development. I wanted to know what is the difference between a SharePoint site and .NET site. When to use SharePoint and when .NET?
SharePoint is a massive "application platform" -- Intranet Portal, External Website, Collaboration Tool, Business Intelligence Agent, Content Management System, Document Retention System, etc -- that utilizes ASP.NET. (SP comes standard with hundreds, if not thousands, of ASPX pages.)
On the other hand, a plain ".NET" site does not need to have SP installed: just IIS with any required ASP.NET extensions.
You use SP when you need it and/or are told to use it. It's Okay -- but generally not teriffic -- at what it does (and it does a lot). But it's big and expensive. (Microsoft "recommends" something like a minimum of 7 servers for a "basic" SP Farm, but it can run as a single instance.)
That's it. Really.
As others have pointed out, SharePoint Foundation is "Free" insomuch as there is no SharePoint CAL or SharePoint server fees. Do not, however, discount the cost of any additional requirements..
SharePoint is a web based collaboration tool built using ASP.NET. The .NET framework (and ASP.NET) is a toolset that allows you to build applications / websites + more.
You can build on top of SharePoint / Dynamics CRM 2011 using the underlying application as a framework providing goodies such ad Security, Logging, Workflow, Persistence, File Storage, Alerting, etc.
SharePoint is an enterprise information portal, from Microsoft, that can be configured to run Intranet, Extranet and Internet sites. Microsoft Office SharePoint Server 2007 allows people, teams and expertise to connect and collaborate. A SharePoint enterprise portal is composed of both SharePoint Portal and Windows SharePoint Services, with SharePoint being built upon WSS. WSS is typically used by small teams, projects and companies. SharePoint Server is designed for individuals, teams and projects within a medium to large company wide enterprise portal.
With ASP.net you have a very well documented, battle-hardened, mature and stable platform with a good API. ASP.net is more reliable, Simpler to customise look and feel. Pages render faster in native ASP.NET rather than being hosted in SharePoint. Server requirements are reduced as SharePoint services are not running/not required. Simpler development and deployment model and debugging (no .webpart & GAC deployment required).
Related
I need to perform the procedure described here, but programmatically.
Some background: I am automating a setup procedure for an existing software product. This product integrates with Microsoft Dynamics 365 for Sales (online, not on-prem) and SharePoint Online. The setup process is, as of now, a manual series of steps. One of the steps consists in enabling server-based SharePoint integration for the organization.
I extensively searched Microsoft's documentation on Dynamics 365, specifically the Web API reference docs, but to no avail. I wonder if someone has had an experience doing this and if it is at all possible; if it is not possible we will be forced to have a manual step involved.
So far I have been working with the Dynamics SDK for .NET, but solutions using the Web API or PowerShell are welcome.
It is not possible.
See this issue in GitHub.
No it isn't, and is documented here: https://learn.microsoft.com/en-us/dynamics365/customer-engagement/developer/integration-dev/get-started-sharepoint-integration#enable-sharepoint-integration
"SharePoint integration for Customer Engagement can only be enabled using the web or Microsoft Dynamics 365 for Outlook. This isn’t supported through SDK."
I've been tasked to create an API where a web page (developed externally) should be able to communicate with a CRM system. I've looked into the CRM SDK and created a couple of C# classes that perform some basic operations to get a feeling of it, but my main issue now is what should I give the web page's developer so that he can use what I have. Does it have to be a REST/SOAP API hosted on the domain of the CRM so that the web page can send queries or can I create a DLL from the c# project and give that to the web page's developer?
In fact, how would it work out if it's a REST API if CRM is hosted by Dynamics/Microsoft?
You are looking to create a wrapper around the Dynamics CRM Api to support development of an application that interfaces with Dynamics CRM. There are two ways to do this:
Create a hosted web service.
Generate a DLL with public methods.
If you are okay with the developer-user having to configure a connection string for Dynamics CRM and the application is being developed in a .NET language and the CRM server is addressable from the location where the application runs than # 2, generate a DLL with public methods, is the easier answer.
If any of those are not true you are likely to find that # 1, a hosted web service, is a better fit.
Need an advice on design approach. I spent couple of hours googling and still cannot come to a conclusion. Task at hand:
design intranet app that will have access control. Users should be given rights to access it.
C# is a preferred design language
app can be a simple form with some text fields and some fields as dropdown boxes from a DB
app will send SOAP request upon form completion
there should be a couple more forms like db search, preferably with sorting ability for columns
There is a Sharepoint I can get access to. Can it easily solve the access rights management or or should create a separate app on the same IIS or perhaps I shold request a separate IIS created and deal with access rights via DOTNET solutions? What is the quickest way to design this in your view?
Our SharePoint is 2010, and professional edition of VS2013 available for development.
Thank you
About SharePoint:
There is a permission management in SharePoint. You can set user permissions up to individual items, files and pages. You can read about it here: User permissions and permission levels in SharePoint 2013 and here: Fine-grained permission reference for SharePoint Server 2013. You can use differend authentication providers (AD, FBA, Oauth etc): Authentication, authorization, and security in SharePoint 2013.
You can create customization declaratively (no code), С# or javascript. There is built in object model (client and server) and web services (REST for 2013 or SOAP for 2010). More about SharePoint for developers
You can use built in form web parts or create custom with server code (C#) or with just HTML and javascript. All you can do with asp.net - you can do in SharePoint with custom web parts. But you can do most of things just with HTML and javascript.
You can request web services from server code (C#) or from javascript - just like in asp.net apps.
You can do db search with javascript or server code, using your prefer datagrid controls.
I think most easy way is using SharePoint 2013 Foundation (it's free if you have Windows Server license). And using javascript and HTML - in this way you don't need to know anything about deploying solutions in SharePoint etc. But you can do it via custom web parts - in this way you may do it like common asp.net development. But it's not a best way.
I looked at forums and some blogs to find out my answer but could not so posting here.
We have MOSS 2007 and a library where we have documents are stored, I would like to run a client utility which runs a day and export all documents imported on that day along with metadata(Column names)
I don't want to install SharePoint server on VHD or on my development environment because I don't think that just for this cause I need to to have Dev SharePoint environment. I don't want to develop this on my development SharePoint environment and give it to my SharePoint team to deploy on server because I feel I should be able to do just on my XP machine.
As SharePoint object model is available, why I cant take missing dll from server and write a small C# utility to export documents to file system? I assume I should be able to do this with SharePoint web service but my question is can I do with SharePoint object model on my XP machine? I don't want to ask my admin to use stsadm to do required work as part of script.
In SharePoint 2007 there is no support for client-side access to the (server) object model. You have to use web services to comply with the requirements you've presented.
Also, it is not possible to take SharePoint DLLs to a client machine without SharePoint installed, and compile—or even run—code with them. It might be possible to achieve compilability, but the process is tedious and makes no sense at all providing it won't ever run on such machine.
You don't need any DLLs from SharePoint 2007 to use web services.
Getting just DLLs be painful for development - you'll be able to compile your code, but to run/debug you still need full installation of SharePoint.
Note that there is special https://sharepoint.stackexchange.com/ dedicated to SharePoint questions.
I would like to upload some files on a server Share Point.
My questions are:
1) I started developing my project as a Windows Service but I read several parts of this WebService. It's mandatory that it's be a WebService?
2) I added the references to. Dll take it from my SharePoint Server (as seen in most discussions) but a little read more shares can not be tested if not solely on where you installed SharePoint Server. Right or there are alternative methods to do this? And also, when we deliver the service, can I install the latter on a machine where SharePoint is not installed (it seems a trivial question, but it seems strange not being able to test
but you install it).
You can only reference SharePoint 2007 assemblies from code that is running on the machine where SharePoint is installed (if you were using SharePoint 2010, you could take advantage of the Client Object Model).
Only the part of your solution that is directly interacting with SharePoint has to be created as a web service. You should create a web service with basic methods like UploadFileToLibrary, deploy it to SharePoint machine and then call these methods from the client (it can be an ASP.NET page or desktop application).
As Kit Menke pointed out in a comment below, it is possible that built-in SharePoint web services will be sufficient for you needs and you won't have to create a custom one:
Upload a file to SharePoint through the built-in web services
Copy.CopyIntoItems method