I've been working with ASP.NET for about 5 years now and I'm looking to get into SharePoint development.
Would it make more sense to get up to speed on SP 2007 first or just dive straight into SP 2010?
Seems like learning SP 2007 would give me a better understanding of the "story" and broaden my work opportunities.
What do we think? Is a grasp of SP 2007 a must for any SP developer at this point?
Thanks
Thanks for the helpful and encouraging answers. Seems the unanimous recommendation is to skip SP 2007 and dive straight into SP 2010 as the dev tools are much better, so I'll probably do that :)
As I wrote in a previous answer I think people starting should focus on 2010. Depending on your work situation, it may limit you in the types of contract jobs you can take, but the development environment is significantly better in 2010. The only reason to start with 2007 is so you can appreciate how much easier 2010 makes it :)
SharePoint 2010 is a completely new architecture and is fundamentally different in many ways. For example, SharePoint Services Provider is no more and the sandbox has been added.
I started with 2007 because that's where we are at work. I think the version being used in your workplace should dictate your decision (unless you're a consultant).
IMHO, starting with SP 2010 would be easier - the support for SP 2010 development comes built in with VS 2010.
I don't think you would gain that much from starting with SharePoint 2007. As the others have said, the development environment with 2010 is much friendlier and doesn't require as many 3rd party tools.
More importantly though, the object model is almost the same. While it is true that SharePoint Service Provider is gone, it is not something that you play with a lot when you develop (in my experience anyway). The important objects and concepts (content types, web parts, lists, list items, etc.) are pretty much the same, which is why I don't think there is much of a "story" to get.
Make your life easier and go with 2010.
SharePoint 2010 is a much easier way to start as others have already suggested. From an analogy perspective, there isn't a lot reason today to learn COM+ programming for instance. You can work with .NET and be happy most of the times.
A couple of real good resources that would help you bring up to speed with SharePoint 2010 are listed below...
http://technet.microsoft.com/en-us/sharepoint/ee518660.aspx
http://technet.microsoft.com/hi-in/sharepoint/ff420396(en-us).aspx
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 6 years ago.
Improve this question
How should an experienced .NET & SQL developer go about becoming a BizTalk expert for a project starting in 1 month? How should I spend my limited time to gain some practical skill & knowledge in BizTalk so I can "walk the talk"?
I am self employed, and would not be willing to spend more than USD300. I have the book "Professional BizTalk Server 2006" by Wrox, but have not found it to be a particularly good learning resource (very dry, needs more real world examples).
The BizTalk Virtual Labs in MSDN are a pretty good place to start with. Pluralsight also has several good BizTalk courses, and their online subscription isn't too expensive; would likely be a good option.
I agree with everything written this far. All solid info.
I have a few addons, coming from a fellow freelancer working with BizTalk since 2002:
Unit testing.
It's not easy to do, but check out BizUnit. A Codeplex based toolset written and maintained by Kevin Smith. One of the early BizTalk heroes :-) http://bizunit.codeplex.com/
Deployment / getting things into production
But also keep in mind that none of the day to day development stuff will prepare you for the part of the project where you have to deploy the app and make sure that it is "manageable" by operations. This can be quite complex, and is a topic in it's own right.
Check out Apress Pro BizTalk 2009, it's got a decent (IMO) chapter on this.
The entire development process around BizTalk.
The first two chapters of the same book will give you a good impression on what a BizTalk project is about. Where to use it, and where to not use it, how to organize projects, and name your stuff. Really a good collection of info that you would only get by reading 5-6 years of blogs back in time :-)
And one last thing. Depending on the roles on the project, you might be asked to optimize and tune BizTalk. And if they don't ask you. Make sure that you ask if others have done that, because you have to do it. BizTalk should always be tuned towards what it is supposed to do. Low latency vs high throughput, tuned according to hardware, correct setup and config of network around the SQL boxes, etc etc etc. This can be hairy stuff, and you should be careful not to jump into it before reading up on it all. But it's a subject we as freelancers are often expected to be able to deal with ... so thought I might bring it up.
Example ... BizTalk x64 processes on an x64 box runs really bad out of the box, actually worse than on the x86 processes. The 64 bit processes need to be tuned to really use all the MEM that are availble to them.
Anyways ... a bag of mixed tips and I hope you can use some of them! And good luck! It can be a tough start, but if used right, BizTalk can be a great product/toolset.
And remember .... if it is ugly, or hard, or both. You are doing it wrong. And don't be afraid to dive into .net code, and bolt it onto the BizTalk box. We all do it ... some just won't admit to it :-D
Start with the advice of tomasr.
Then, try and build something as real as possible. Biztalk is the kind of product where everything seems fine when you read the book and follow the examples, then you sit down to do something and you are thinking "what do I do now".
As per Thomas and Shiraz - set up an environment and get your hands dirty. If you haven't done so already, download and install BizTalk Server 2010 Developer Edition
But just to temper your expectation, IMHO expertise in BizTalk (or any other EAI / BPM / ESB product) can take years to accumulate.
It isn't clear whether you are developing for a client with an established BizTalk installation, or if this is the client's first BizTalk deployment. If so, one thing not to be underestimated is that the operational considerations of running a production BizTalk environment (performance, redundancy, reliability, auditing, tracking, monitoring with SCOM etc) are as complex as the development and testing - but understanding of this will be important to 'walk the talk'.
W.r.t. dev, start with some a simple EAI type mapping project, and then work your way through the SDK samples progress to some common messaging patterns (e.g. batching with aggregator), and then move into the BPM type orchestrations. You can probably leave BAM and the BRE for later.
Good luck!
+1 to tomasr for mentioning the virtual labs. Getting hands-on is definitely the way to go, as Shiraz Bhaiji also mentions. Hopefully you're not starting with BizTalk 2006, and can go with the latest: 2010. If that's the case, you can get the Developer Ed. of BizTalk 2010 for free now (see link from nonnb).
I'd also recommend Richard Seroter's book: 'SOA Patterns with BizTalk Server 2009' (available on Amazon.com). There are many ways to do the "wrong" things with BizTalk, and this book does an excellent job of walking through both the how and the why of building BizTalk solutions (with the code samples available from the publisher's site). And yes, it pretty much takes a whole book to go through it all. It's a good (more readable) companion to the Pro BizTalk 20xx series (which is generally better for very specific questions/tasks).
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 5 years ago.
Improve this question
I work on a team with three other developers and one business analyst writing internal business applications. We're primarily building apps in ASP.Net, and do so in a very 2003-ish way. It's like going back in a time machine. Although two of the other developers are amenable to learning new things, one of the developers is not. He's the type who thinks he's the strongest developer in town, and that if he doesn't understand a new tool within 5 minutes then he just needs to build his own. He also doesn't recognize agile development, TDD, or basically any non-Microsoft-blessed tool or method. He even considers source control from anything other than SourceSafe to be dangerous. To his credit, he's a brilliant programmer, just not someone interested in software development.
So the only way I can get consensus is if a tool is really easy to use. Once we hit a single snag, he'll lose faith in a "I told you so" sort of way.
So what set of tools should I use to get us into a modern source control system, TDD, and CI? The obvious choice in my situation seems like it would be Microsoft's TFS, but I doubt I could get our thrifty and apathetic management team to spend the extra money (they already think MSDN Pro is too much).
Basically, what is the easiest set of tools to get going with Source Control, TDD, and CI for a .Net 2008/2010 environment?
I wouldn't recommend dumping all these tools and methodologies on your team at once, take baby steps. Introduce one at a time. Some will come naturally.
There are many good choices, but I can personally recommend these:
Source control: Subversion with TortoiseSVN and Ankh or VisualSVN
Continuous Integration: CruiseControl.NET
TDD tools: NUnit + your mocking framework of choice (I use NMock, though it's a bit old-school). I agree with commenter Eric that TestDriven.NET is a must-have, particularly if you want to make this easy!
These are easy to get started with because they're all good products, reasonably to very well-documented, and widely-used (so it's easy to get help).
It's always going to be difficult to introduce new tools if you can't build a consensus. Focus on building the consensus, rather than on the tools.
SVN is very good (with Ankh and TSVN), but it can be a bit surprising to people used to SourceSafe.
TDD is a technique, rather than a toolset, so you need books, blogs, etc. For tools to support it, NUnit or MSTest. Continuous Integration is a must-have. CruiseControl.Net is pretty good (though a bit difficult to configure initially). Consider also TeamCity.
Do you have a bug-tracking system?
Oh, and if your management team is that apathetic, consider quitting.
Update: you've said that they're not so much "apathetic" as "hands-off". Question: are they really hands-off, and will they let you move things along? Or are they "status quo" -- "it ain't broke, so don't fix it, and don't rock the boat"?
I think you can make a really really good case that within the last two years Agile has become completely and totally embraced by Microsoft. I know for a fact that the Codeplex, MEF, and ASP.NET MVC teams are quite steeped in it. I also think that visual studio and parts of the windows 7 team are Agile. Also consider that Visual Studio 2010 includes out-of-the-box refactorings that don't really make much sense outside the context of TDD and that Agile is the default project management template for TFS and a picture of a corporate culture that is quite different from the one of years past starts to emerge.
As for specific tools. TFS is OK for source control but I find it very heavyweight and finicky. Others have mentioned Subversion but if you're worried about MS blessings you might have better luck jumping straight to Mercurial. Its a more advanced SCM but it is now supported natively by Codeplex and has excellent windows integration. I've never used it but I am in deep tool-love with it's cousin git.
Test driven development: Start with MSTest, its not as slick as anyone would like but its not the worst thing in the world. I would also recommend MbUnit which has all of NUnit's features along with some good support for the integration tests that you will probably be writing by accident as you are starting out with testing. Oh, and if you have customization freak I would urge him to look at XUnit.Net.
Mocking: The choice is basically Rhino Mocks or MoQ. Here's a quick intro I wrote for Rhino Mocks that goes over all the basics. That being said, the trade off seems to be more documentation for RM versus a very mildly less error prone syntax for MoQ.
Test Runners: If you start out with MSTest you'll notice that you can get a significant speed boost in your test runs by using TestDriven.Net, resharper or coderush rather than the built in test runner. That being said, don't underestimate the standalone test-runners. They can be quite good every once in a while. I heavily recommend Gallio Icarus runner which comes with MbUnit.
I want to echo what George Mauer has said and suggest starting with MSTest for your unit testing. It's right there in the box to begin with Visual Studio, this will help in your cause as it's "MS blessed".
I would start with unit testing and take it from there, after a few months of "look how easier our life is now we have these tests automated" I'd take it up a notch. Consider adding something like Selenium or WatiN to the mix. Once you're rolling with that, get your CI server up. "Wouldn't it be great if we didn't have to start off all these tests manually?..."
I guess a decent SCM might be a sticking point. SourceSafe is better than nothing. Perhaps start using Mercurial or Git yourself? Show those open to the change the benefits, eventually your stubborn dev will come around when others around him are wanting to switch. Hopefully, he'll find it harder to shout if he's in the minority.
Check out http://www.viget.com/extend/effectively-using-git-with-subversion/ for ideas with mixing up different SCMs.
I also want to +1 mxmissile for saying to take things slowly. I think you'll find it very difficult to introduce all these changes in one go. It's a lot to take in at first if you're not used to it. Try to pick the part you're weakest on, or will add the most value and build up from there.
Good luck!
One tool that got me hocked on TDD is TestDriven.Net which puts the test results in the Output window. I mapped this to the F8 key and the productivity gain is superb; write a test, press F8 and see this results in the output window.
One suggestion I also have to differentiate between having Unit Tests and doing TDD. I have found that TDD can be hard to push on to a team, while; unit, integration or functional tests are an easier sell. Having a bunch of tests that saves an hour going through a manual test day after day is a big win.
After a while people will start to appreciate some new ideas if it is helping them in their daily life. Then you'll be able to introduce a build server, and move away from SourceSafe.
In .NET environments, Microsoft Visual SourceSafe is most frequently used. (but it costs). Next to that you can opt for SVN or GIT. Git is more recent (and gaining popularity). It's easier to work with than SVN once you get it.
http://git.wiki.kernel.org/index.php/GitSvnComparison might help with your decision.
Recently I witnessed an acquaintance developing an ASP.Net site with SQL Server 2005 and Visual Studio 2008, and I was blown away by his level of productivity.
I mainly develop servers and sometimes Windows Forms applications. I only do a ASP.Net project every once in a while. So, when one comes up, there's usually a little bit of ramp up time to get my productivity back.
This guy, he was developing complicated .aspx and .ascx pages with seemingly little effort.
How can I become that guy? What are the secrets that I should know?
Experience is the best productivity boost I could ever hope for.
To me, "secret" is a word used to sell books more than anything else. Nothing is really a secret when it comes to software development techniques and patterns.
I think the key to being highly productive is to gain a very solid understanding of software development patterns, and to be reasonably proficient with your technology of choice.
There are no real secrets (well, aside from that one I won't tell you) but, basically, the trick is to use things that do your work for you.
Unit testing
ORMs
Deployment tools
Build tools
etc. There are many many others. But generally, try and avoid doing work, and focus only on actual 'application-specific' things.
At least that's what I do.
A note of advice: Asp.net has everything you need out of the box to develop small website. You will be able to do practically everything you want to do. Practically. And then you start hitting the virtual ceiling and it takes considerably longer to implement what you thought would be a simple change. Basicly, asp.net is a leaky abstraction (interesting article) when you start to do medium and larger websites.
Anyway, back to your actual question, to keep the productivity level high, avoid the AJAX.net stuff. Use jquery, dojo any other library instead.
I am undergoing BizTalk server training in my company.
I have almost 6 years of experience in both Microsoft and Open Source like PHP mostly in web applications.
Does it make sense to learn Biztalk server for my future career?
In short Will it help me to improve my profile?
Please advise/suggest.
Learning anything that is an active and vibrant technology will help you and your career. I don't see how this could be qualified as a negative in any aspect.
Even if this particular product goes out of use, it's useful to understand the problems it is intended to solve and the general approach. Don't get too hung-up on details though.
You may want to look at New Features in BizTalk Server 2009. It's not dead yet.
i have been doing BizTalk server development for years and it has most certainly helped me be an early adopter of the SOA / Contract first / Loosley coupled application fad that is sweeping through the industry ... why? well because as BizTalk developers we've always done this stuff. it aint new to us.
so yes, learn it. it can't do you any harm at all!
This question is similar to my earlier question.
I have used ASP .Net in Visual Studio 2005 about 4 years ago. How long would it take to get back up to speed with the latest versions?
That depends on how much you "used" it. An experienced developer should have no trouble updating his knowledge of the 3.0 to 3.5 Framework changes and language specific changes. The largest introduction, I'd say since then has been LINQ, giving the ability to query data from the language level rather than SQL.
But if you're not an experience developer and don't have a good foundation in the previous version, most of what you'll be learning will be the Framework 3.0 and VS2005.
So, ultimately, if you're just going from VS2005 to 2008, it shouldn't be much trouble at all.
Not very long. The major addition to VS 2008 is support for Linq, but you don't have to use this (or any of the new features).
The IDE is extremely similar to VS 2005.
Essentially, 2005 targets the 3.0 framework, and 2008 target the 3.5 framework, but these are both just expansions of the 2.0 framework, and not new versions (unlike the change from 1.1 to 2.0).
If you were already proficient in it earlier, then you'll be able to jump into it very quickly again. The core concepts haven't changed much, so you should feel right at home.
If you were able to produce and application back then, you can probably still build exactly the same application now.
As has already been stated, .NET v3.5 is merely v2.0 with extra bells and whistles, like LINQ and AJAX. These are tools in a broader toolkit, and there is no requirement that you must use any/all of them.
So start where you left off. Refresh yourself, and once you are back in the swing of things, have a look through some of the latest enhancements, and pick out one or two that you think will be useful to you. One step at a time!
Everyone else is correct that it should be easy. I'd just add that the ListView control is one of the additions, so be sure to check that one out.
It depends on what you want to use ASP.NET for.
If you live in the HTTP Request/Response world, it will take time. Most of that time will be spent trying to shift documentations which completely ignore the Requrest/Respone world in favor of ViewState and other similar items.
If you want to go ViewState way, not too long, since Microsoft's website is overflowing with tutorials on it.
Take a look at some of the starter kits like Kigg, DinnerNow, and DropThings . You'll get an idea of MVC, WCF and LINQ. Ignore that sinking feeling and get to work learning!