I'm starting with Sharepoint.
I have a simple C# application using a database.
I want to show it in Sharepoint2007, and my boss told me that I have to do it with a WebPart, but I've been looking for information and I haven't found it.
Sharepoint 2007 web parts are difficult to build because you need to programmatically build up the presentation layer in your code.
You should definitely use Smart Part as this allows you to develop Web parts like they are user controls in a conventional .Net application.
You should also read up on Sharepoint patterns and practices as it is fairly different in certain aspects.
You could possibly use (see link below) to show data from the DB.
http://blogs.technet.com/b/paulpaa/archive/2010/01/26/data-view-web-part-to-view-data-from-non-sharepoint-database-adventure-works.aspx
However if you want more adaptability and the feeling that you know what your doing(I guess your a developer with some knowledge of c#)
You would possibly be best off going down the coding route. I always say work smart not hard!
Get some tools to make your job easier. WSP.builder for one(Codeplex) and start with something very simple. People say theres not much use in the hello world but it's a great place to start when learning how to deploy, Debug your first sharepoint web part.
What i would advise is.
Read up on how to use WSP builder. This will help you build your Sharepoint projects with the required structure.
You will want to use visual web part feature within wsp builder for this.
Once you know how to deploy this, Should come with reading around wsp builder! you should be well on your way to getting your web part done.
If you ever find it hard keep at it SharePoint can be a tempramental beast! Theres a wealth of knowledge on google exploit it!(Work smart not hard;))
Also if you have your own development area back it up! If it breaks you don't want to have to rebuild it i learnt the hard way!
Hope this helps
Related
Many thanks #Mirko for the reply and comment. So sorry if im not clear myself.
I'll try to make it alot more understandable.
First thing is, I want to create an application for a Data Entry Form on Windows (Windows Form Application .exe). This application required database
and for a database server im thinking about SQL (Need some advise here on the server).
After the Form-Design completed and linked to the database, i want it to be able accessing PDF/PNG and stamping also, For approval purpose. Thus i need some file transfer server for this and some new coding line for this function. (I need a lot of help here especially the coding line).
Please note i've also tried making a form-based application on VBA Excel and use it's sheets for the database. But im struggling on how to make an access for File transfering and stamping (Approval) protocol. Thus lead me to C# on Visual Studio, hoping this coding program could handle such file-embed system.
Edit: Nico, I am not sure this will make a great SO question. Sorry, I cannot provide this detailed feedback in comments as they do not allow enough text. You are asking for advice that is in my opinion too broad. Meaning you really have many considerations here and are in essence asking (I think) how do I build a document management and approval (workflow) application.
You may want to look into document management solutions (I am no expert on those), but many handle approval flows and meta-data on documents well.
I would recommend you carefully consider even your starting assumptions. In my opinion if you are building a green-field application now you should decide between WPF (instead of Windows Forms) and a Web Application (that is in the .NET space) and I would probably recommend ASP.NET Core Razor Pages. If more than one person will use this application I would lean towards the latter strongly as it is more easily accessed and updated.
I am not the best person to answer how to do the Stamping approval part, but you may want to consider either an existing document management solution (maybe DocuSign, etc. as an integration) as they may offer you the features you are looking for out of the box. If not take a look at PDF libraries in the .NET space (I personally used Aspose in the past, but they tend to be expensive).
If you are looking to track metadata about the documents to be uploaded/approved SQL server is often a good choice, but since you are quite literally seeming to aim for document management, more document-centric options maybe a good fit (MongoDB, Cosmos (Azure), DocumentDB (AWS), ...) as they allow you to store arbitrary meta-data.
I have a company that needs a document management system.
I have looked at SharePoint but it has far to many bells and whistles. The company wants something that doesn't have intranet portals, app downloads and all the other waffle (they simple don't have the skill nor the inclination to spend thousands learning it).
I am finding that SharePoint is a little like a fork-lift bus truck car. It trying to be everything to everybody which usually ends up useless to all.
My question is does SharePoint Foundation work out of the box as a document management system or is it like an engine you put your own code upon.
The more I read through Google the more conflicting information I come across without any clear definitions.
What I want to end up with is a document management system that has authentication and a simple page / screen / whatever to link / admin to those documents.
As per usual Ill probably end up having to write my own but it would be nice to not keep re-inventing the wheel.
SharePoint definitely has a learning curve, there's no getting away from that. However you don't need to set up all the "bells and whistles" if you just want a basic DMS.
To answer your question, you don't need your own code to get a SharePoint site up and running. You will however need to spend quite a lot of time figuring out what configuration you need for your needs.
We're using SharePoint 2010 Foundation as a simple document repository in a couple of web apps and it works fine. No Wikis, no versioning, no custom pages. That stuff is availablem but we don't need it so we don't enable it. The nice thing about it is the security which hooks into AD so authentication can be set up easily and it is robust. Our DMS solutions are accessed via the internet by users, and internally by apps, and SharePoint can handle that fine by setting up alternate access mapping so that you can get to documents via internal and external URLs.
I won't lie; I've spend a lot of long days cursing SharePoint, but it's still a far better solution than what I could have come up with myself.
In case your wondering, we're using 2010 rather than 2013 because we had been using WSS 3.0 up until this year and you can't upgrade directly from WSS to 2013. But since we only need the basics, doing a second upgrade to 2013 wasn't worth the effort.
The truth is Sharepoint can be used as a sort of document management system (ish). But in truth it is far to over complicated and has gone rather off at a tangent from the demos I was original given when it first came about in the beginning. Alfresco an Nuxio are probably much better. (but even they have their issues). You simple have to look at all three and make your own decisions as now I know this is not a simple question. I personally went for Alfresco but for very exact reasons, even it has some issues but generally speaking it is the best(ish) out of the three. (Nuxio would of been best except for its 'purchase your admin interface' model.
I'm just looking for some advice really on CMS choice. The website will need some kind of CMS for sure, because the requirement is that the end user is able to add multiple "project case studies" under a bunch of different categories, and also spawn separate pages, and change general bits of content around the site. It's quite simple really, but the site needs to be easily navigated where these case studies are loaded via AJAX requests.
I'm looking closely at Orchard, a .NET CMS based on MVC2, but it seems kinda like overkill for the project - it has a bunch of features I'd never be using on the website and I don't want to overdo it. Plus, it's still a little bit buggy because debug messages keep coming up looking for debug classes that don't exit.
Any advice would be awesome!
Thanks!
No matter what CMS you choose, it's likely to have stuff you don't need, as a CMS is necessarily casting its net very wide. It is supposed, after all, to be able to manage any kind of content.
I'd like to understand what you mean by "debug messages keep coming up looking for debug classes that don't exist". Can you elaborate, maybe on a PM so I can understand if that is a real bug that we should fix.
When it comes to opensource .net cms, I had very good experience with N2 CMS. You can check it out on GitHub: https://github.com/n2cms/n2cms
There was a discussion recently, regarding whether to use Umbraco or Orchard as a backend for ASP.NET webstie/application. You could try reading this, I guess you'd find a solution there.
I have less information about share point (only basic info). Microsoft released SharePoint for web developers. Microsoft also said SharePoint has compatibility with other .NET technologies like Workflow Foundation, WCF, etc and it's easy way to develop web sites and web apps.
Also as I know ASP.NET has compatibility with .NET technologies and C#. And it easy for every one whom at least work with C# or VB.NET.
So with these advantages of SharePoint:
Why we must use asp.net instead SharePoint?
Why Microsoft develops ASP.NET (new version 4)?
What's major reason to chose one of these?
Is really developing base-on share-point faster and easier than asp.net?
SharePoint is an Application that sits on top of ASP.net (3.5 SP1 in the current SharePoint 2010 - No ASP.net 4.0 will be possible). They do override a lot of ASP.net built-in functionality (they have their own .aspx Parser and Virtual Path Provider for example).
With ASP.net you have a very well documented, battle-hardened, mature and stable platform with a good API.
With SharePoint you gain a poorly documented, bug-ridden, very limited application that handles a lot of features that you would have to code yourself (e.g., User Profile Management, Document Organization and Versioning and Social Features like Commenting and Tagging), although for the most point SharePoint handles them really poorly and does not allow you to override them, which means that you spend a lot of time rewriting them anyway and trying to integrate them back.
Basically my advice as a SharePoint developer since 2006: Use it when you absolutely have to, avoid it whenever you can and stay with just ASP.net.
SharePoint is good as a simple document management and very light social system. You can quickly customize smaller parts of it and add a lot of value to your company. But in the moment you need something that even only slightly different from what Microsoft envisions, you hit a wall that you can't pass. It's great for what it does, nothing more, nothing less.
I am a Sharepoint Developer... And let me say that I wish it was just ASP.NET! That would be great... It brings with it it's own paradigms which are pretty complicated.
ASP.NET and Sharepoint are 2 'different' technologies. Sharepoint is mostly built with ASP.NET, and delivers ASP.NET pages to a user.
You can use either VB.NET or C# with Sharepoint.
In my opinion, Sharepoint development is only quicker if you are planning on using it's in-built lists, user management etc. Though these do take time to learn. The cool thing about sharepoint is that you can develop web parts, and re-use these web parts on multiple pages throughout the installation.
Microsoft continues to develop both ASP.NET and sharepoint because they are two different beasts, with ASP.NET pages being deliverable through Sharepoint.
As to which is best for you, you haee to make that call. Do you need Sharepoint? Or would a pre-built CMS such as DotNetNuke be better? Or even creating your own site with Windows credentials management so you can use SSO (Single Sign On).
It really depends on what you want to get out of your install. Sharepoint is expensive, and developers for Sharepoint are also expensive because of the specialist knowledge.
As a developer... (I hope my boss isn't watching!!) I much prefer to build things from scratch than to use SP, but that's my job...
Don't use sharepoint unless you need it, check this article:
Challenges when using SharePoint compared to ASP.NET
If you just want to create a website, go for ASP.net.
However, if your company has a SharePoint installation and you want to integrate with that, you should go for SharePoint.
SharePoint is build on ASP.net, but has many extensions that allow data to be shared throughout the company.
However, if you are just building a website and don't need all that, ASP.net is the way to go.
I'll try to answer point by point:
SharePoint isn't a replacement for ASP.NET. It's an extension of the ASP.NET platform that simplifies the implementation of several common use cases that are mostly relevant to enterprise websites: document management, knowledge retention, collaboration etc... SharePoint relates to ASP.NET in a similar way that Wordpress relates to PHP: it's a specialized extension rather than an alternative.
Same explanation as in (1).
Use SP if the things you need to develop are in the scope of what SP provides, which is mostly enterprise solutions of one sort or another. Here's a good summary of what SP can do.
Again, it would be faster and easier if you're trying to develop the things that SharePoint is meant for. Also, SP isn't so well-documented, so if you're not familiar with it, you might have a slow start.
SP is a very powerful platform, however, it does seem to bring complexities to the table that otherwise may not be there with simple ASP.net. Plus when you move "OOTB" with SP it becomes a bit challenging with RTM, etc. I live in blogs with "weird" things that happen. I am not a full blown SP developer but have been working with it for over 7 years and well, I find building solutions that will work within SP, but not necessarily built withIN SP generally are going to be easier to maintain and controllable. Just my opinion!
I would compare all for you and its up to you to decide.
ASP.NET >> Its a programming language by Microsoft which means you would need Windows Server + IIS + Database server like SQL Server + some Anti Virus on the server.
Say now you need some more PC for your servers and so your costs go up all the time you need a new server
Sharepoint Server are again from Microsoft and so everything above applies.
At my place of work I've been put in charge of creating a coding standards document. Generally we follow what FxCop and StyleCop tools report to some degree but what we really require is document that will explain when to use a convention, why and maybe even a simple example.
This could be extended in the future for other purposes as well.
The first thing that came to my mind is to have an internal wiki site that we could build up and change easily over time but I've never used a wiki-based engine before and would like some recommendations.
If possible the engine should be in C# so we're able to tweak it to our needs if required.
If you think a wiki solution is the wrong way to go about this then please give an alternative :)
Update
I've just been informed, although we do have a php server it wont be staying, so I'm afraid php-based wiki ideas are off the table.
Update 2
Could you also (if possible) let me know if any of these solutions work with Active Directory?
Cheers
Tony
ScrewTurn Wiki is an free and open-source wiki made in C# and ASP.Net. Different database back-ends can be used, like MSSQL and MySQL, but also works without any database. It has several plugins to work with Active Directory.
Mindtouch Deki
Great wiki and it's built on C# and PHP, so you can use it on Mono or .NET
It also has Active Directory integration.
Download their ready-to-use VMware image. It started using it on my own PC then moved it to the company's VMware server when they had it ready.
We keep an internal wiki at my shop that has almost all of our documentation (not just coding standards). We didn't really see the need to roll our own so we just used MediaWiki...
We use JAMWiki and love it.
It is a solid application, we have had nothing but good interaction with both the application and the developers.
The guy you maintains the code does a great job answering questions and helping users out.
Brad Abrams has published an online set of C# coding standrds:
http://blogs.msdn.com/brada/articles/361363.aspx
If you go to the starter kits section of the Microsoft ASP.NET site, you will find several wikis to download such as ScrewTurn and Flexwiki. A wiki would be ideal for your needs by the sound of it :-)
I second MediaWiki. It's not C#, but it can be a nice excuse to sneak some free software in through the backdoor.
If you guys are a Microsoft shop, though, and are using Sharepoint, it has some built-in wiki-esque functionality.
In one project that I develop, I set up one MediaWiki wiki for development documentation, and one for online help.
I even generate part of the development documentation right from source code and database.
At the shop I'm at they use a commercial package which is really good: Confluence. What's especially nice is that it integrates with LDAP/AD so that you don't need a seperate login and it's build especially with business use in mind and has lots of free plugins. We couldn't live without it.
I am confused by what you mean when you say you don't have a php server. It runs on every platform known to man. I am noticing most Visual Studio Developers don't know that PHP runs on IIS.
I would go with mediawiki It has the biggest feature set and most add-ons developed for it in case you ever need to port your data elsewhere. If you need to modify your wiki you are doing it wrong.