Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I've just started a new software consultancy business and I'm currently putting together designs for my website. We will be at a stage very soon to start converting these into a template for a CMS.
I have used http://n2cms.com before, but my designer has built many sites using WordPress, we recently built a site which worked very well and I was very impressed by the WordPress admin.
So I might be a bit risque and build my site in WordPress, host on Azure, even though my consultancy specialises in Azure & Silverlight :)
What's your thoughts? Can you suggest any other great .NET CMS's that would sway me away from WordPress?
Any suggestions much appreciated.
Cheers,
Ash.
P.S. Anything that uses Table Storage would be cool, and would be much cheaper!
I agree with Gabe that true Azure support from a CMS means leveraging the cloud's native queue, table and blob storage. I'll also add that a good Azure CMS should work out of the box when deployed on numerous machines sitting behind a load balancer (basically a must if you care about Azure's SLA).
I myself did a research similar to yours a couple of months ago and ended up using N2CMS in an ASP.NET MVC application. AFAIK, there is still no CMS to comply with the above definition of good Azure support, so I would recommend going with N2 if you use ASP.NET MVC. The learning curve is a bit steep, but you mentioned you've used it before so this shouldn't be an issue. However, the great architectural flexibility N2 allows and the fact it's open source were the decisive points in my case.
Regarding Wordpress, there's no arguing about the qualities of this CMS. Anyone who's used it (including myself) should be able to confirm that. However, deploying Wordpress on Azure still feels somewhat "hacky" to me. It will no doubt work, but I personally try to use native solutions and that's the reason I went with a .NET CMS on Azure and I always use Wordpress on Linux servers. I believe that's the right approach if you plan to maintain your application in the long run.
In the end, the choice you have to make is a trade-off between many factors like your in-house know-how, your preferred technologies, etc. If you need rather quick results and have Wordpress guys at the moment - go for Wordpress. If not - I recommend ASP.NET MVC with N2.
Well, at least that's my 2 cents :) Hope this helps.
Ash,
There is new free open source CMS called Composite C1. Just couple of weeks ago company released source code to CodePlex (before it's was 100% commercial). C1 provide you full control on layout (XHTML, XSLT) - your designer will love it... also it's build on .NET 4 and using C#, LINQ.. allows create quickly functionality..very flexible...and user friendly.. for example you can edit several pages at same time.. it's uses XML as data storage, so no need for database, but there is commercial module which allows easy move to SQL. Company having workshop today regarding Azure (check Community tab at the website) and looks like will take required actions in this directions (no time frame available).
DISCLAIMER: I work in Composite’s QA group, so this is not an unbiased suggestion ;p but I've moved my personal website to Composite C1 (from Umbraco) and quite happy!
The Orchard Project seems to have much potential if you want to be risque and still stick on the .NET application programming platform stack.
From the website:
"Orchard is a free, open source, community-focused project aimed at delivering applications and reusable components on the ASP.NET platform. It will create shared components for building ASP.NET applications and extensions, and specific applications that leverage these components to meet the needs of end-users, scripters, and developers.
In the near term, the Orchard project is focused on delivering a .NET-based CMS application that will allow users to rapidly create content-driven Websites, and an extensibility framework that will allow developers and customizers to provide additional functionality through modules and themes.
Truly supporting Azure means tackling the cloud storage challenge. As you mention, this means using native Azure storage (table, queue, blob) to persist data. To my knowledge, there isn't any CMS that has truly addressed Azure storage.
It's easy for a CMS to claim Azure support by using SQL Azure. This isn't true Azure support though. SQL Azure databases get capped at 50GB...which means they aren't infinitely scalable. Any solution that is using SQL Azure isn't infinitely scalable.
--
All this being said, I work for Telerik and we have an ASP.NET based CMS called Sitefinity. Version 4.0 of Sitefinity is coming soon and it runs using Azure & SQL Azure. If your database will never exceed 50GB, then this might work for you.
We've discussed creating support for native Azure storage in future versions of Sitefinity. However, I can't give an ETA.
--
Ultimately, I agree with others though; if you're happy with Wordpress, then use it.
Sitecore has a special edition that was design for Azure.
Sitecore Azure Edition
VIM4, Composite C1 is not support the IE10 for Windows8 CP. :(
This is meant to be a comment to Mark Good's answer, but since i don't have enough rep - having to post as an answer.
Sitecore does not have an edition called Azure, it is rather just Sitecore with the Azure module installed. We have talked to Sitecore before about this, and their sales engineers confirmed that was correct. It's semantics, but could be important in certain cases. Cheers!
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am in the process of architecting an application. It will be a large, enterprise class web application. Thousands of users could upload files, search large number of blog entries with chat functionality and such. It will also have mobile interface. It should be highly testable, scalable and flexible.
I have narrowed it down to three environments: pure play ASP.NET, pure play DotNetNuke (DNN) and a combination of ASP.NET and DNN. To keep this very brief, here are some 'for' and 'against' on each of the options:
ASP.NET:
for: highly scalable, supports patterns like MVC, testable, consistent architecture.
against: long development time.
DotNetNuke:
for: short development time, large number of existing functional modules and skins.
against: architecture is sealed, can't support MVC, unit testing is difficult, inconsistent modules/skins, potential upgrade issues, user experience is inconsistent due to disparate modules from different vendors, poor documentation.
So, the questions are: what do you think? Has anyone switched from DNN to ASP.NET (and, vice versa)? Have you objectively evaluated these two and what did you choose?
Highly appreciate your help. Thanks.
henry.
DNN is ASP.NET, just with a lot of the work done for you.
Also, please remember that just because raw ASP.NET has the potential to be more scalable, doesn't mean that you are actually going to built it to be more scalable. Or that you will built it well in the first place.
It comes down to a trade off between control and resouces/talent. If you have many very talented developers (like, top-10% talent), a lot of time, clearly defined requirements for your site, and consumers who will be patient while you build out the infrastruture, by all means go with raw ASP.NET.
However, if you need to build it quickly and need to be flexible, or you have limited development resources, you might have to sacrifice some of that control and unit testing and potential performance (again, the "potential" part is key here).
Based on what you are looking for, I'd recommend you go with a platform like DNN, or a million other ones line SiteFinity or Umbraco or Orchard or something like that (some of them like Umbraco give you MVC too). It gives you a lot of the infrastructure and plumbing common among a lot of sites, probably done better than you are going to do it, so that you can focus your resources on the truly unique aspects of your application.
Just stay away from SharePoint. It's evil.
I've built raw ASP.NET sites for really customized applications, which was good because I didn't need a lot of plumbing and wanted really unique funcitonality through the site. But then I've built social networking sites with DNN, which worked well because it had packaged components for blogs and forums and chat and all that stuff, plus allowed for easy skinning. I designed another application for a customer that they wanted to have a lot of custom functionality, but they also wanted to updated a lot of content and internatalized it, so we used a Umbraco for that. And right now I have a ASP.NET app that works great, but I want to add in some social features, so I'm going plug in a Umbraco or DNN site that integrates with it to host the more common social components.
I would definitely recommend DNN based on your very limited list of needed features. You can always build a custom module to meet your exact needs or modify an existing open source module as needed. You can use the MVP approach in your module development to improve the testability.
Have you considered the Umbraco CMS? It is built on .Net (v5 is MVC3). It is open source and a very robust and well supported application. It has been used for the asp.net site for example.
It has a very short development time, many modules, extremely flexible and I find it very easy to extend. For example, I rolled my own workflow, event driven publishing and have created multiple custom administration sections for managing bespoke functionality external to Umbraco.
You can use XSLT, Usercontrols or Razor to create template modules.
It has a fantastic community too.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I am tired of having to manage projects manually. We use subversion for version control, but ultimately, I want an app that can:
Send out notifications to clients on the progress of their projects
Allow clients to log in and see screenshots of projects
Keep track of money paid, as well as invoice due dates and how much is outstanding
Allow clients to post any queries regarding the project in an area
Manage several projects
I currently use
SubVersion
WHMCS --> would be great if it could integrate into this
Any suggestions would be great? Or might I have to write an app like this myself?
Redmine
Redmine is a flexible project
management web application. Written
using Ruby on Rails framework, it is
cross-platform and cross-database.
Redmine is open source and released
under the terms of the GNU General
Public License v2 (GPL). Features
Below are some of the main features of
Redmine.
Multiple projects support
Flexible role based access control
Flexible issue tracking system
Gantt chart and calendar
News, documents & files management
Feeds & email notifications
Per project wiki
Per project forums
Time tracking
Custom fields for issues, time-entries, projects and users
SCM integration (SVN, CVS, Git, Mercurial, Bazaar and Darcs)
Issue creation via email
Multiple LDAP authentication support
User self-registration support
Multilanguage support
Multiple databases support
Go Redmine site
You should definately check out Gemini. This has loads of awesome features and can do all of the above (plus a whole lot more). Also, we'll be bringing out some great new functionality on the finance side in the next few weeks.
Dave
I've been looking at Redmine: http://www.redmine.org/
As of now, I've only been looking at it for my 2 person company, and as it integrages subversion and other version control system directly into projects, I think it's an OK choise.
But as mentioned, I haven't used it in production like environemts yet, but it look well tested.
There is also a Turnkey version of it, which is ready to be used as a live CD or in a Virtual Machine: http://www.turnkeylinux.org/redmine
/Kristoffer
If you are looking for something that is hosted I would consider assembla.com. It has just about every feature you could want, and has worked really well for me in the past.
http://www.assembla.com/
We use PivotalTracker
Doesn't have all the features you mention, but it is useful for client interaction and project management.
You could write the app yourself, but you'd likely be better off just going with a SaaS! Believe it.
Your software needs are a bit ahead of what traditional project management apps offer, and it is likely you'll find many systems to be insufficient.
Warning: Just because most PM apps will be insufficient doesn't mean you should settle with multiple different apps. This will lead to double entry, inefficiency, and a list of other problems that come with apps that don't integrate properly. You're better off with something that combines everything you need into one system.
You could try WORKetc, they have a 14 day free trial and combine all the core essentials for web devs. CRM, Project management, collaboration tools, billing, support tools, email marketing, and even client logins (invite clients/contractors to check on projects you're working on related to them + they can collaborate).
WORKetc combines key tools so that it can be used to manage an entire small business. Combined alerts, reminders, calendars, to-dos, document sharing, and a bunch of other features. Worth looking into, other than that I'd recommend looking at the Google Apps Marketplace. Cheers!
It all depends on the size and scope of your projects.
I would say that JIRA is the best system available at the moment and if you only require a small number of users (<=10) then it is only $10 a month.
It's definitely the most complete system out there but obviously there is the hurdle of cost and getting it set up (there is a lot of initial set up to get workflows and things working how you like them).
I've started to wondering whether ASP.NET Webforms/MVC even have a place in the web developers toolbox anymore... It seems that CMS systems like Umbraco have replaced the web developers job. Yes I know that those CMS systems are built with ASP.NET Webforms/MVC - however is there even any reason for learning those things if all you gonna do is to use a CMS system anyway? - Also I cant find any situation where a CMS system can be replaced by your own web application.
My question is therefore: Is there any reason for learning Webforms/MVC when using a CMS?
EDIT:
My question might be more like: When should I use a CMS, and when should I go and build my own web app?
The problem with CMS solutions, and I mean all CMS solutions (not just Umbraco, or other .NET solutions, but in any language) is that you will always pay a price for using them. You may gain more from the time-savings afforded by using the CMS, but there are trade-offs to consider:
You will sacrifice a great deal of flexibility
You could pay a significant performance penalty. Many CMSs load a large amount of modules and code to service every request, and much of this is not relevant to a particular page function. (though some CMSs are more monstrously heavy than others!)
The future of your project is tied to yet another vendor, and their own choices
Very often, you rule out the possibility of using other databases that might have better fit your customer's needs (Umbraco doesn't support PostgreSQL, Kentico only supports SQL Server)
Once you start using a CMS you will be tied into satisfying the architectural decisions and API of the CMS framework, and you could eventually be backed into a corner.
This can be particularly problematic if your 'site' is more of a web application than a pure content delivery site. In such cases it can make more sense to choose to build using the full flexibility of the web application framework, rather than risk getting backed into an architectural corner.
On the other hand, if you are building a web site that has potentially hundreds of pages, with a lot of user-contributed content and is much less of a web application, then often a CMS is the way to go, and makes a lot of sense. But remember, you now have two frameworks and two APIs to learn and manage (your platform's framework and the CMS framework).
Writing a CMS is like invading Afghanistan.
Everybody gets a turn but nobody wins.
I don't think that Stack Overflow could have been built with a CMS. Does that answer your question? =)
Update
To answer your updated question.
If you want a regular corporation web containing news, articles, forum etc: Go ahead and use a CMS.
If you need to build a more custom web site like stackoverflow, a web interface for a system or anything like that: Built it using MVC etc.
I personally use a CMS for our corparate website and a MVC framework to build user and administration interfaces for our products.
Not every problem needs a CMS. In the same way not every problem needs a bespoke MVC/webforms website. It depends on what your requirements are. You pick the technology to solve the problem.
Build vs buy is the hardest decision to make. As a developer build always looks best. You can do better than that pile of carp they want to buy. Nevermind that you're reinventing the wheel, axel, cart, etc. To users/management buy always looks best. They don't have to think to hard about what they want and can have it now, not 3 months later after you write it. They forget it'll cost the same again to customise & make it impossible to upgrade.
I'll stop ranting now.
Umbraco is a pretty bare minimum CMS. To customize it (e.g. Version 7+) you'll need to know Heavy MVC, JSON, XML, Sql, etc.
In fact a Site built on Umbraco 7+ is entirely based on MVC views you set yourself and assign to SurfaceControllers (which are MVC controllers) and all you are really getting is the ability for users to edit things about your pages and have Umbraco manage it for you in a DB.
In short you still need experienced web developers to build a site on Umbraco, they just save a lot of time by not having to build the entire backend from scratch.
You use Umbraco to organize Document Types that define what Templates (MVC Views) are used for rendering different types of documetns (e.g. Web Pages) and then you built the template from the ground up with 100% control over the HTML, Css, and Javascript that get's output.
Imo Umbraco is more of a Framework like Django than a complete CMS.
Sure you can build a site in Umbraco and not customize anything, but it would be a pretty cheesey site.
The whole point to Umbraco is to give skilled .Net Developers a good platform for building a site on top of it, but they still have to build it.
Now sharepoint would be more of a complete CMS out of the box that you can do a lot with, but let's see a few problems with SharePoint...
Resource Heavy, eats 50+ Gig's to install
Eats 16 GB of ram just to boot it up (Sharepoint 2013)
Requires Sql Server 2008 R2 or equivalent (enterprise license, $$ chaching)
Requires Windows Server ($$chaching)
It's a monster basically, if all you need is a user editable blod platform... man what a waste of money. Foundation is free, but doesn't include things like the Blog Site Template, so you buy a server enterprise license ($$ big cachinge, 40,000$+ in some scenarios...)
Agreed. A CMS like Umbraco provides a (very) good out-of-the-box solution for the most basic applications. Any sort of specialized purpose is going to require additional programming knowledge. Anymore, though, and your major, if not primary need is going to be a good understanding of the business need. I think we're getting away from building the Legos themselves and on to building the neat toys with the Legos. Cheers!
A CMS (or similar application framework) will provide you with a lot of functionality out of the box, and many of them also have a good library of plug-ins. But you'll still need to write WebForms/MVC code if you want to add any custom features.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Our team is divided on this and I wanted to get some third-party opinions.
We are building an application and cannot decide if we want to use .Net WPF Desktop Application with a WCF server, or ASP.Net web app using jQuery. I thought I'd ask the question here, with some specs, and see what the pros/cons of using either side would be. I have my own favorite and feel I am biased.
Ideally we want to build the initial release of the software as fast as we can, then slow down and take time to build in the additional features/components we want later on. Above all we want the software to be fast. Users go through records all day long and delays in loading records or refreshing screens kills their productivity.
Application Details:
I'm estimating around 100 different screens for initial version, with plans for a lot of additional screens being added on later after the initial release.
We are looking to use two-way communication for reminder and event systems
Currently has to support around 100 users, although we've been told to allow for growth up to 500 users
We have multiple locations
Items to consider (maybe not initially in some cases but in future releases):
Room for additional components to be added after initial release (there are a lot of of these... perhaps work here than the initial application)
Keyboard navigation
Performance is a must
Production Speed to initial version
Low maintenance overhead
Future support
Softphone/Scanner integration
Our Developers:
We have 1 programmer who has been learning WPF the past few months and was the one who suggested we use WPF for this.
We have a 2nd programmer who is familiar with ASP.Net and who may help with the project in the future, although he will not be working on it much up until the initial release since his time is spent maintaining our current software.
There is me, who has worked with both and am comfortable in either
We have an outside company doing the project management, and they are an ASP.Net company.
We plan on hiring 1-2 others, however we need to know what direction we are going in first
Environment:
General users are on Windows 2003 server with Terminal Services. They connect using WYSE thin-clients over an RDP connection. Admin staff has their own PCs with XP or higher. Users are allowed to specify their own resolution although they are limited to using IE as the web browser.
Other locations connects to our network over a MPLS connection
Based on that, what would you choose and why?
I am especially interested in hearing from developers who have experience with both ASP.Net and WPf.
Reasons to choose WPF:
Much faster and easier development than ASP.NET and jQuery
Much easier to implement quick incremental background loading of data
Much easier to implement client-side caching of commonly used data (important for remote offices)
More efficient data transfer from server (can use advanced WCF features unavailable to web browser)
Keyboard navigation better, since you can easily define shortcuts, etc, and not be limited by browser
Maintenance overhead much better using MVVM pattern
Softphone integration easy
Reasons to choose ASP.NET and jQuery:
None that I can see
In your scenario I would definitely choose WPF.
First of all, I would sit down and write the business requirements and specifications. It really doesn't matter what tech you use - proper planning will affect your project timeline more than technology choice. This is especially true for an in-house custom built app.
As far as development, I would take the requirements and lay out the backend functionality. I would actually implement the backend in WCF, regardless of the client technology - that way you could use best of both worlds if needed (for example for phone integration you could write a stand-alone WPF app). ASP.NET with jQuery can easily use WCF services (JSON or XML version) together with desktop client.
As far as development of the client forms, this highly depends on developers experience and your future plans. I am not going to go into advantages/disadvantages of developing web software here - there are a ton of articles in the last 10 years about cloud/web based software (for example salesforce). I would rather concentrate on deliverables - what is your team most comfortable with today and in the future. There's a huge difference between WPF and web development, from development standpoint, and it requires completely different experience.
Why not consider a hybrid solution - Silverlight
With Silverlight you get most of the goodness and statefullness of WPF (with almost exactly the same XAML and code), plus you get the deployment characteristics of ASP.NET
Many people consider Silverlight the next step after ASP.NET/AJAX, and it would definitely deliver all of the benefits of WPF relevant to your scenario.
WPF is the way to go, without a doubt. I agree with all that #Ray Burns has said.
Because:
You will get a richer, slicker, faster application.
It will be easier to build1.
Softphone/Scanner (i.e. hardware) integration is going to require browser plugins etc. and this can be a nightmare with a browser based application.
Keyboard navigation is still better with native applications.
IME Maintenance is easier with WPF applications.
Definitely use WCF to provide the backend via The Entity Framework, see The Entity Framework In Layered Architectures. You can do have a better integration with the backend in a native application because it can be called inline - no need for callbacks or ajax. I've built components for WPF that are linked via EF to the business logic to provide aware controls for simple stuff like validation. It's stunningly good to drop a customer name field onto a form and it just works.
To add additional components you need to build it with a proper well thought out plugin architecture. This is the same in both environments. I've got some thoughts on this I jotted down in my journal entitled Designing a plugin architecture for an application
When building a WPF application you will be writing in one language (e.g. C#) + markup (XAML). When building asp.net you endup with two languages + markup, as you always have to code some Javascript.
So, based on your requirements it has be to WPF / WCF (EF). A web based application will be a lot more work, more complexity, and not be as nice.
About 12 months ago I was fortunate enough to be given a free hand to choose the technology for a new application. I spent almost a month evaluating all of the options and came to the conclusion that it had to be C#, WPF, Entity Framework. After writing the application I can confirm that it was the right choice...
1. It will still be easier even if your programmers have to learn WPF first. WPF is much better thought out, great and lovely. very lovely. It just works right.
Hi
I think The question at issue is Windows-application or Web application(WPF for win-app VS asp for web-app), Which one is better for you and your project?. In this case your platform is network and your program must work on the net. so for this usage Web-app is better but there are a lot points existing which can make decisions hard. Network platform has great challenge.(according to my personal experience)
Working with web-app by asp.net is nearly hard. you must try to handle many thing's for web-app(request time, session management, even poor UI in comparison to WPF, j-query, etc ). Remember this is not as easy as simple web site.
But win-app is good for network with this condition: "local network"(mpls is almost the same). Absolutely developing win-app is easier than web-app ("At least number of users expert in net-program developing"). for this case WPF has many good things(UI , command, etc) also has many challenging point(like multi-threading and lack of expert developer in this field ) . I'm rather with wpf than asp but decisions is yours
And chalk point to good thing Silverlight but if you want to use this you must look at prism framework : http://compositewpf.codeplex.com/
I have recently developed a project separately with asp and silverlight(prism framework). developing silver-light version is too hard and takes more time than asp.net version but at the end SL-ver have great look nothing else!
Burns pointed to good issues about wpf. also consider Artemiy's post. your environment conditions is same for both of them. WPF/ASP can work with scanner and soft-phone cuz the base of both is on C# and .net library
Finally what ever your decisions is you must hire advance developer at least develop one business-app for the network platform.
Is your app a desktop app or web app.
If Desktop wpf is best.
If web based asp.net is best.
Don't front load your development with your get it up quick scenario. That never works well and results in a sloppy deployment. Take your time, cover all the steps (Business Requirements, System Design, Program Design, Code, TEST and TEST some more, Deployment)
Some points to be made for ASP.NET:
The pool of ASP.NET developers is much larger then the pool of WPF developers.
Which means you can probably find qualified ASP.NET developers easier.
ASP.NET is probably more future proof, chances of WPF getting large changes and being hard to port to later versions is probably larger.
Also keep in mind that the focus of MS seems to be on Silverlight so there might be a consolidation down the road which makes WPF obsolete.
More mature eco system of ASP.NET makes for more out of the box solutions to use to solve problems.
With multiple locations you might be able to skip a few layers and go directly to a website?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
This may be an opinion based question, but it's something that I wanted to ask (even if it does end up getting closed or deleted).
I do custom app dev (asp.net/aspMVC) and have absolutely no knowledge about sharepoint and was wondering:
If you have a "rock solid" custom app dev, asp.net/aspMVC web developer can he jump into sharepoint development fairly easily? What about the other way around? Does a seasoned sharepoint developer have the "chops" to do custom app dev using asp.net/aspMVC?
By no means do I want to offend any sharepoint developers or any custom app dev developers. I'm merely trying to see how much knowledge you can take with you when going from one type of development to another.
I recently put a very strong .NET guy from my team through the SharePoint learning process and let me tell you, it’s no small task. The issue is not so much familiarity with the SharePoint object model or product architecture (he was quite familiar with the latter), it’s more about understanding the “SharePoint way” of doing things.
Let me expand a little; the main thing is the concept of working locally on a host system goes out the window so you need to work on either a VPC (which you may need to build from ground up) or a server which also has the appropriate development tools installed. Some people even run a Windows server product directly on their host machine but you’d want to pretty dedicated when this also involves running SQL Server and SharePoint on your PC.
The next thing is it’s not simply a matter of opening up a SharePoint site and writing code against it, it’s more a matter of building individual webparts and features which can then be deployed. This also involves some very obscure configuring of XML files which if done incorrectly, can have a very negative impact on the entire environment (i.e. things just stop working). Finally, the deployment process is completely different. There is no simple “publish” option like you’d have with a normal ASP.NET environment rather there is a convoluted process of deployment and activation.
SharePoint does a lot of things really well but when it comes to writing custom applications it has an uncanny knack of making things that are normally very simple extremely complex. You reach a lot of crossroads where it’s either the SharePoint way or the highway and if you’re not aware of these upfront you run a serious risk of the effort required blowing out significantly. Don’t get me wrong, it’s a great product, I’m just saying don’t approach it with the attitude of “it’s just .NET development” and expect things to go smoothly.
IMHO, this is a very large jump for a .NET developer and shouldn’t be approached unless you’re serious about moving into SharePoint development. I’m quite explicit in my environment now that unless someone has real world experience developing for SharePoint they should not be jumping in and “learning on the job”; the risk is just too high.
BTW, there is a good question titled What are your biggest complaints about Sharepoint which you should read.
I know a (little) about SharePoint and to a large extent you can pretty much code in SharePoint if you are a .Net coder.
There are a (lot) of quirks you need to be familiar with though.
WebParts for one. These are
available in WebForms but they take
on new meaning in SP.
How and Where the pages are stored.
SP, if you make a change to a
standard page, stores the changed
page in a database and references it
from there so if you go looking at
your file system for your file,
you'll find it but it'll be the wrong
one.
I think the page life cycle may be
slightly different but don't quote me
on that.
That's just to name a few.
To sum up though I don't think you can just dive in and begin coding. I think your best option is to either get a SP developer to teach you or to do a course.
I did an SP course and to be honest I still don't think I could just dive right in and get it right.
SP punishes you harshly when you don't do things the SP way.
I am in this position and getting into MOSS (am certified for configuration) but it is not easy to understand as there are new concepts when developing for MOSS (eg webpart production). BUT it is just a new process and a lot to understand about MOSS and how it works.
My limitation is not doing enough of Sharepoint 2007 at work so obviously I am going to be lagging behind in webpart creation, etc. But this is why I am going to install the software at home.
On the other hand, Sharepoint development is C# and ASP.NET, so in the codebehind/presentation, you have a solid base.
If you code Sharepoint, I think Winforms is easier so you can switch to that ok. ASP.NET and Sharepoint 2007 share A LOT of concepts as Sharepoint is pretty much a very advanced ASP.NET web application so you can go from MOSS to ASP.NET.
I develop Sharepoint applications since 2002 and ran successfully dozens projects based on it, ranging from .
Starting with WSS 3.0/MOSS 2007 most Sharepoint specific technologies (aka webparts) was incorporated into .net; so, application development changed a lot: you don't need to eat SPWeb on breakfast, but being a regular ASP.NET developer and having a pragmatic approach to learn about content management it's enough.
Bottom line: Sharepoint development isn't rocket science; don't be afraid, get a VS2005/8, a VPC and happy coding!