What is difference in developing applications using .Net Framework, Asp.net and developing application in Sharepoint (MOSS or WSS)?
Sharepoint is a collaboration tool built on top of .NET and ASP.NET. To develop applications for Sharepoint means you still need familiarity with ASP.NET and the .NET Framework, but also familiarity with the Sharepoint infrastructure/API's.
I highly recommend checking out this thread for various pain points:
https://stackoverflow.com/questions/256407
Since SharePoint is built on ASP.NET, the argument can be made that anything you can do with ASP.NET you can do with SharePoint but the reality is developing applications for SharePoint is not for the faint-hearted and you should expect a much longer development cycle, particularly if you are new to the platform. I suggest becoming very familiar with Google, StackOverflow, and .NET Reflector because a lot of what you need to know is not in the documentation or hard to find.
It's not all bad though. You get a lot of infrastructure out of the box like authentication, versioning of data (if you are storing your data in lists), and incoming/outgoing email connectivity to name a few.
Depends on what sort of stuff you want to do really. There are many points in SharePoint that are exposed for you to build on. For simple requirements one of these points of development will suffice but for typical business applications on SharePoint you use a combination of features such as workflow, event receivers, timer jobs, web parts, sites and lists. C# code can run in a workflow, an event reciever, the code-behind library attached to an infopath form.
Essencially SharePoint gives you a collaboration platform to develop on to enable all sorts of things. Be warned thou, it certainly isn't as painless as straight C# development and requires lots of technologies and thus lots of new learning. However it's a been a very rewarding experience for me.
SharePoint is working with canned but modifiable website templates (WSPs) inside a of an system with a really long feature list-- including an abstraction over the data store (lists), the templating engine, work flow features, etc, etc.
The other is custom development of websites from scratch.
You can have it both ways. SharePoint itself was build with ASP.NET 2.0, so you can host aspx and with some effort ascx pages inside of SharePoint. Once inside SharePoint, any custom written .NET code can take advantage of the SharePoint object model. This works best if a custom application from the start is planned to be hosted in SharePoint.
Deploying your solution. SharePoint uses WSP files while ASP.Net supports copy/paste.
Think of SharePoint as a framework that sits on top of ASP.Net. There are rules to use this framework, try your best to abide by the rules.
Related
I was given a project in WebForms to make robust and I had so far added several improvements to it. Don't get me wrong, I like WebForms for its simplicity but much of it is I feel like 'grandfather' type of coding.
Here's what I did, just to give you some ideas:
1.) Added VueJS to the frontend
2.) Added Webpack and a bit of ReactJS to on some pages
3.) Used .NET core on running a custom protocol app that triggers from inside the WebForms project
4.) I've added an emailing function (Inbox, Sent Items, Drafts, Trash, Junk, etc.) (from WebForms and jQuery, another one was WebForms + VueJS) to it as well.
It has gotten pretty big. I was just wondering if it will be scalable? Our management is thinking of putting it on the cloud soon but I believe it wouldn't work because of the architecture of our project - we will have to slowly transition it to modern web standards (apply MVC, use WebAPIs rather than WebMethods (static) on CodeBehind files).
I really am lost. What's the best route in improving a WebForms project to modern standards? Something scalable and cloudable (if that even is a word).
Thanks.
(Let me reach for my flame-retardant underwear.)
The big difference between WebForms and more contemporary web design frameworks is that WebForms attempts to layer an event-driven forms management paradigm on a platform that is not built for events. Web pages are not desktops.
In my experience, the efforts to maintain the illusion of web events in a complex application far outweigh the investment in taking the original functional requirements to MVC, or NodeJS, or React, or some framework that is designed for the calls and responses of the stateless servers of the Web.
I vote do-over. You will have to do your own cost/benefit analysis if you want to take that route. If you do go that way, this forum is a good place to post specific questions with code samples related to coding problems that you uncover on your journey.
I'm trying to figure out various pieces that need to go into building for the mobile web with .NET / C#. I've so far been working mostly with native app development (iOS / Droid / B'Berry) and have very little experience with web development in general. But for the current project I'm working on, I believe a web-app is the way to go and would like to figure out what I pieces I need to get it working.
To give a brief overview of the application, our company uses SQL Server / .NET / VS for all of our web dev projects. The programmers here are familiar with this stack and I would like to keep it that way if possible. We're building a new product that needs a web + mobile view. The web view is currently being built as a separate project completely, but that can be changed if needed.
I'm just looking for some input on how to design something that handles screen resolutions, device types etc. and creates layouts appropriately in VS. Also, any best practices when trying to do this are much appreciated.
Thanks,
Teja.
handles screen resolutions, device types etc. and creates layouts appropriately
This is all presentation layer and shouldn't be a concern for any development framework. Sadly, it is. For instance, I'm currently working with a JSF team and so much of the presentation layer is produced via the JSF framework and it's a nightmare to maintain a sane presentation layer code base that way.
.net used to be that way too. Much of the early days of asp.net was full of invalid markup, bloated generated JS and the legendary postback cache tag.
Ideally, you'd have a presentation layer team that was independent of the particular framework. Mobile apps, more than anywhere, require the ability to maintain a lean, streamlined presentation layer and the best way to handle that is to let your team write their own HTML, CSS and JS as needed. I've worked with a C# team that was heavily using RESTful services that worked fairly well. We had built our own template framework and all HTML, CSS and JS was completely independent of the back end C#.
Fortunately, MS has gotten better and newer ways to implement via asp.net (such as the MVC model) can hopefully offer you better management of the presentation layer.
Technology: ASP.NET 4.0, C#, forms/mvc
I am a .NET web designer and I wish to create a modular based website for people, similar to what DNN does (but I want to create my own cut down version).
The idea is that I create a base website that can 'activate' features which the client needs (and has paid for). These features may be used by many clients which require frequent future updates for all clients (so I wish to keep upgrade time down to a minimum).
For example, I upload the base web application using web deploy and it sets up the core database tables/views/SPs in the process.
Then I login into the website as developer and activate the out of the box features that I wish to permit the user to take advantage of.
The only way I can think of currently is via user control, resources etc..
But I need a little of your experience and advice over what the possibilities / dangers are....
e.g. images for an application e.g. blog, that I have activated for a client - how do I reference those images
e.g. Can user controls be dynamically added to a web application (which is pre-compiled unlike a website - it must be a web application since I am using web deploy).
e.g. Modification of web.config to add additional routing (doesn't matter if app has to go down to do this).
The idea is that I can upgrade websites features en-mass, rather than manually enhancing each individual website which given a certain amount of clients would result in an awful amount of time lost.
I do not have access to sharepoint (nor do I intend to).
Any advice on how to automate modularity completely via a front end in asp.net would be superb!
My main problem is how to reference files and resources outside of the websites directory and without using virtual directories (ideally - but open to suggestions).
Thanks,
Dan.
I would suggest that your idea sounds like an ideal scenario for WebParts. There are lots of resources on how to go about building a WebPart management structure from scratch. Then, in terms of your 'bulk update' facility, it would simply be a case of tweaking database entries that are used to configure which web parts a user sees.
I'd be interested to know what you decide to do.
Best
Ian
Try a Multi-Tenancy Architecture as you can find some good info here :
http://codeofrob.com/category/10.aspx
http://weblogs.asp.net/zowens/search.aspx?q=Multi-tenant+ASP.NET+MVC+%E2%80%93&o=Relevance
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.
I need some help figuring out whether it'd be a good idea to use a CMS or portal solution for my latest project, which is (currently) an ASP.NET MVC application that must serve multiple customers (being a company or some other entity with a list of users) from a single installation (that is, a SaaS solution).
In addition to the core functionality, which includes document management/publishing, I also need to provide basic social features (such as blog, forum, gallery, polls, etc.). However, it is imperative that content is only visible for the customer to which it belongs, and my evaluation of a bunch of CMS and portal solutions has shed little light on whether they support this. They're pretty focused on single-user installations, and documentation on how to integrate with an existing MVC solution is pretty thin.
Essentially I'm looking for some guidance to help me discard dead-end options (the product does not meet requirements, imposes too many restrictions, is not mature, etc.) and find unexplored options before getting too far ahead with the project.
My requirements for the architecture include:
Multi-site support (using a single domain for hosting)
Watertight separation of content between customers
Full integration across components/features
SSO (single-sign-on)
Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
Ease of development and deployment
Custom logic will be written using C# and ASP.NET MVC and any products should support this
I want to stay in control
Solution should offer features but otherwise stay out of the way (for example, not force stupid idioms on me, like insisting on GUIDs for primary keys)
Active development community
No single-man efforts
Recent source control activity
Reasonable levels of documentation and maturity
Does not have to be open source
I have spent a fair amount of time evaluating products and components, which I'll briefly share here:
Umbraco
Does not support ASP.NET MVC (yet, as someone is bound to otherwise comment)
Great community support, active development
Seems to be lots of work to get started
Kooboo
No source activity (no updates for almost two months)
GPL licensed? (need something that allows for closed source applications)
N2CMS
Partial ASP.NET MVC support
Every customer must have a separate domain
Limited source activity (not dead but not vibrant either)
Orchard
Microsoft-sponsored (which means it's likely to be over-architected, code-bloated and slow, although it does have some well known and respected contributors/leads)
Built using ASP.NET MVC
Looks promising feature-wise (but is unlikely to be stable at this stage)
AtomSite
Feels reasonably mature and has decent documentation, albeit with holes
Built using ASP.NET MVC
Limited source activity, single developer
MojoPortal
Looks good for a portal, but probably requires custom logic to be built as modules around the product (I was hoping to avoid that kind of lock-in if possible)
DotNetNuke (DNN), CommunityServer and Microsoft Office SharePoint Server (MOSS)
Definitely not my cup of tea ;)
BlogEngine.NET
Mature and feature-complete
No ASP.NET MVC support
Integration possible but not without lots of Web.config voodoo
Not sure if it supports customer separation
Given the list above I'm leaning towards AtomSite, N2CMS, Orchard or BlogEngine.NET. If I go with the latter I'll be using jitbit AspNetForum, which is a great match for my needs.
I'd probably prefer to use a custom ASP.NET MVC solution and individual components as this is likely to give me the greatest amount of control, but on the other hand, it'll make site theming and integration harder. What combinations have you tried, what worked well and what didn't? Anything important I'm leaving out of my evaluation? Any other relevant advice?
I'd appreciate it if the answers were not simply endorsements of your favorite product or way of doing things, but something that would help me choose or eliminate solution candidates given the requirements outlined above.
With the level of requirements you've specified, I'm personally going to have to lean towards the custom approach. You can hire someone to do the design (view) portion of the site for you, or you can buy a theme off the internet from site designers and customize it to your liking. (Sometimes just having somewhere to start is enough for intermediate level customization).
Multi-site support (using a single domain for hosting)
You're probably going to want to have control of your hosting environment, either a VPS (Virtual Private Server) or a dedicated box. This is still possible on shared hosting but not reccomended.
Watertight separation of content between customers
You'd probably have to spawn a unique app-pool for each customer with thier own services user for 100% seperation.
Full integration across components/features / SSO (single-sign-on) /Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
This is going to be the tricky part. This Example may have some useful insight for you in the development process, but you're going to want a unified login service and have all sites use it or link to it.
Ease of development and deployment
This is where it gets tricky. Development ease comes from your background I think. MVC is definately the right choice in this respect then, knowing a lot about the right ways of going about building a site in MVC will aid in this process. Keep up to date by reading community blogs and listening to podcasts like Hanselminutes or DotNetRocks will help keep you in touch with the newest and greatest tools/technologies for making your site get off the ground quickly and effectively.
Deployment is the tricky spot. MSDeploy still isn't quite there. But if you can you probably will want to come up with a Dev -> Staging -> Release publish structure so you can test your code in a staging (mimiced production) environment.
Custom logic will be written using C# and MVC and any products should support this
I want to stay in control
If you develop the site in ASP.NET-MVC, you'll be able to build common libraries that you can use not just in your site, but also in your custom tooling. This will greatly reduce your code duplication and helps make sure operational unity is achieved. (Everything works the same way).
Solution should offer features but otherwise stay out of the way (e.g. not force stupid idioms on me, like insisting on GUIDs for primary keys)
While you'll have control in this situation, I'd strongly reccomend GUID Primary Keys. This allows Merge Replication, which can help you easily restore backups or use failover DB servers when things go awry.
Active development community
.NET has a great community out there, (including this one) and you should get lots of support if you ask for it politely.
No single-man efforts
Not sure what you mean here, You'd be the Single-Man unless you hire help, but even 2 people can do great things given a little time. Even one-man can do great things, but the framework you're running on here is backed by a commercially funded huge team.
Recent source control activity
Doesn't really apply to .NET, but a lot of the libraries that you may use (NHibernate, MVC Contrib, AutoFac, Etc...) will have lots of activity and constantly being improved.
Reasonable levels of documentation and maturity
.NET and most of the production level libraries developed for .NET (Mentioned above) actually have a pretty good degree of documentation. There's multiple paid & non-paid sources of information for .NET alone, and most libraries (are well supported by the community and known on StackOverflow)
Does not have to be open source
Look for support libraries that are LGPL (i.e. you can use it in commercial software, but if you modify the library you have to release the new library code if you release the binary.) You're pretty safe here, your site dosen't have to be open source if you use these libraries to support your development.
Well, that's my 2cents. The project you've described is no small job, you're looking at a considerable amount of work even if you go with a pre-built solution (mainly hacking it to work the way you want). I imagine your biggest hangups would be SSO & Security for the pre-done solutions. Not to say it's impossible, just tricky and the end result may not be exactly what you're looking for.
Also, look into OpenID, it may be the best solution for linking all your sites together and most pre-built systems can easily be ported to use it.
Take another look at MojoPortal. The CMS is awesome and the main developer , Joe Audette, is very responsive. I'm have several installations of the CMS running single and multiple sites.
I would lean towards a CMS based solution. Having a tested and production ready software not only reduces the development time but also helps in continuous upgrade and reduced bug count.
If you go down this route, you may want to also consider Sitefinity. Not only does it support all the features required by you, but also is built on .NET and supports MVC development. The product is built by Telerik, the makers of UX tools.
Disclaimer: I am employed by Telerik.
I've recently come across phpFox which is a social networking/forums/community site CMS. This may be of use to you and is fairly inexpensive.
The solution for the site of our company has become EBIZ CMS: full-featured site that includes social networking, online store, features a presentation, a forum, create HTML pages and much more, including the maintenance of professional technical support, so we do not even need help for installing by a programmer, and it is only US$ 9/month!