Wednesday, November 18, 2009

Workflow for Sharepoint 2010

TFS 2010 and Sharepoint 2010 are quickly headed towards purchase and adoption by IT organizations of enterprises all over the globe. I'm determined to get up-to-speed on any changes to the Sharepoint Workflow functionality. I found a collection of videos at to help techies get up-to-speed. However it takes 22+ minutes to watch all 5 videos so I planned an approach that should work in grasping all this new info. Here are my steps.

(1) See for the latest in Workflow features for Sharepoint 2010.

(2) Go to and click on the "Test your skills" button to really learn the main ideas to grasp.

(3) look at the code snippets at,

(4) speed read through Paul Andrew's article.

(5) Plan to return to with your earphones during your lunch break to watch these videos.

And finally ....
(6) repeat steps 1-4 more carefully in order that you master the material.

A similar approach could be taken with the other 9 modules at for getting up-to-speed on the Sharepoint 2010 platform.

Wednesday, July 22, 2009


The ExecAdmSusJob command of the StsAdm utility is important to use in your Sharepoint deployment batch files.

Tuesday, April 21, 2009

MS-DOS script to remove a SharePoint solution

If you have a SharePoint solution (i.e. .WSP) that you'd like to remove then you could build a 4-step script to run in a MS-DOS script as follows. Just substitute the name of your .wsp file in both places here where it says MySolution.wsp.

"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe" -o retractsolution -name MySolution.wsp -immediate -allcontenturls

"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe" -o execadmsvcjobs

"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe" -o deletesolution -name MySolution.wsp -override

"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm.exe" -o execadmsvcjobs

Wednesday, February 18, 2009

Deploy a WSP without WSPBuilder using STSADM

For SharePoint development I typically use Visual Studio and WSPBuilder to do all my packaging/deployment of my code through .WSP(s). However its important to remmember the procedures for doing it directly through STSADM. At a DOS prompt you want to do the following:

1. Go to the directory where the .WSP file is located.

2. Add the directory containing STSADM to the DOS path.
@set PATH=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN;%PATH%

3. Add the solution:
stsadm -o addsolution -filename AlexSolution.wsp
stsadm -o execadmsvcjobs

4. Deploy the solution:
stsadm -o deploysolution -name AlexSolution.wsp -immediate -allcontenturls -allowGacDeployment -allowCasPolicies
stsadm -o execadmsvcjobs

5. Activate the feature in the solution:
stsadm -o activatefeature -name AlexFeature -url http://localhost

What version of SharePoint am I running?

1. Find out your server name and the port number for SharePoint Central Administration. In my case its moss2007vm1 and 41819.

2. Go to the Settings.aspx page in the Layouts folder - i.e. http://moss2007vm1:41819/_layouts/settings.aspx

3. Look for Version under Site Information. In my case its

Which one?

MOSS 2007 or WSS 3.0 Cumulative update (KB956056 & KB956057)
MOSS 2007 or WSS 3.0 Infrastructure Update (KB951695 & KB951297)
MOSS 2007 or WSS 3.0 post-SP1 hotfix (KB948945)
MOSS 2007 or WSS 3.0 post-SP1 hotfix (KB941274)
MOSS 2007 or WSS 3.0 post-SP1 hotfix (KB941422)
MOSS 2007 or WSS 3.0 SP1
MOSS 2007 or WSS 3.0 October public update
MOSS 2007 or WSS 3.0 August 24, 2007 hotfix package
MOSS 2007 or WSS 3.0 RTM
MOSS 2007 or WSS 3.0 Beta 2 TR:
MOSS 2007 or WSS 3.0 Beta 2:

Source: Penny Coventry's blog at

Monday, February 16, 2009

Creating Custom Lists in SharePoint Features

One of the fastest ways to feel extremely ill as an IT worker is to read and analyze a schema.xml file associated with a SharePoint list of a SharePoint feature solution in Visual Studio. These files are thousands of lines long, cumbersome to read and make the Oracle SQL*Forms files I dealt with on my first internship in 1989 look like a piece of cake. There must be a better way to create/customize SharePoint Lists for a custom Feature. The good news is that there is and here are the steps:


1. On your dev SharePoint site create the custom list with all the attributes needed. For this example I'll suppose the site URL is http://moss2007vm1:81 and the new custom list is named MyCustomList.


2. Create an empty subdirectory in the c:\temp drive of the dev virtual machine called MyCustomListCode.


3. Go to a DOS prompt on the C: drive of this virtual machine and type in: CD "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"


4. Type in: STSADM.EXE -o ocdexportlist -url http://moss2007vm1:81 -name "MyCustomList" -dir c:\temp\MyCustomListCode


5. Examine the contents of the c:\temp\MyCustomListCode directory and see that there is a schema.xml file and a few .ASPX files for the custom list. Move these files into the MyCustomList subdirectory of your Feature in Visual Studio.


6. Compile the Feature and build the WSP. Verify that the Feature is not activated on your site and that the custom list is not on your site. Then deploy the WSP to your dev site and activate the Feature and verify that the custom list was successfully created.


Suggestion: If you need to add lookups or dependencies on other features/lists this is possible with the schema.xml file and other XML config files in your solution and associated Features staplings. However I recommend adding such things AFTER the lists are created in custom code called from the Feature's FeatureActivated event handler.

Monday, January 26, 2009

Becoming an OOTB SharePoint Guru Quickly

At is listed a few quick-learn skills that can turn a techie into a capable SharePoint administrator.

* Control the Quick Launch display… tweak, collapse and hide
* Let users manage the interface with the click of a button
* Hide major chunks of the interface that are just not needed on some pages
* Allow manual resizing of web parts on the page
* Expand and contract all groups in a list
* Manage your own resources for creating other basic, interface interactions

Warning: To get more out of SharePoint requires some very serious experience. But there is plenty of value with SharePoint out-of-the-box (OOTB). That's why its such a popular platform.

Thesaurus for SharePoint

Download for a MS Excel spreadsheet that generates the file. Name this file tsneu.xml and place it in the "C:\Program Files\Microsoft Office Servers\12.0\Data\Office Server\Applications\\Config" directory on the MOSS server.

Kudos to Mauro Cardarelli at for this idea.

Top 15 SharePoint Blogs

According to Technorati and Joel Oleson the top 15 SharePoint blogs right now are the following:

SharePoint Blog URL

See for details.

Skills of a SharePoint Architect

Read to see a good list of skills for a SharePoint Architect. Joel Oleson breaks the recommended skills into 4 areas: Core, Solutions, Extended, Interop/Integration. Here's his long list for Core.

IIS 6/7, Windows Server 2003/2008, DNS/WINS (Name Resolution), TCP/IP, SQL Server 2005 Admin (Backup, Monitoring, Logshipping or Database Mirroring), Basic Firewall rules/Proxy, IT Infrastructure Design, Hardware Acquisition (RAM, CPU, Disk I/O, etc.), Performance Monitoring, Capacity Planning, Growth Management, Windows Workflow Foundation, Client Troubleshooting & Support (IE, Firefox, Safari, Office XP, 2003, 2007, etc.), HTML & Client side scripting (Javascript, AJAX, DHTML, XSL, XSLT, XHTML), Exchange/SMTP integration (Inbound/Outbound email + contact objects), High Availability (Microsoft Cluster Services, Windows Network Load Balancing), Storage (Appliances, HBAs, SANs, Archive Storage), Backup Solutions (Various Tape, Hardware and software snapshots, software nearline and offline storage, DPM 2007, etc.), Hardware load balancing & ISA Secure Web Publishing, IAG (Internet Application Gateway), Whale Communications, Single Sign on integration, Connection Monitoring & Troubleshooting (ADO.NET, Web Services, CDO), Global Deployments & Multi farm deployments, Environments (i.e. Dev, Test, Staging, Production - Staged deployments), SDLC (i.e. MOF, ITIL, MSF Frameworks), Virtualization (Virtual Server 2005, Virtual PC, VMWare).

Read his blog for his list on Solutions, Extended and Interop/Integration. Being a SharePoint Architect is no easy skillset to master overnight :) Perhaps its best to track which skills are most associated with SharePoint. See for the following list: .NET, Microsoft, SQL Server, C#, ASP.Net, SharePoint Server 2007, Windows, SQL, MS Excel, XML.

SharePoint performance limitations

Read to get a reminder that SharePoint needs to be implemented wisely with performance issues in mind. A few notes to glean:

1. Many envision SharePoint as a replacement for their regular network file shares. Keep in mind the "2000 document limit".

2. Even taking appropriate topology and taxonomy steps, heavy file-based SharePoint usage is going to significantly reduce the "rated" capacity of a SharePoint environment.

3. Consider if the users are geographically spread out. Would you want to channel all of the current file-server usage in your remote offices through a single WAN link?

4. Remember that SharePoint itself resides on a Windows server, and stores everything in SQL Server databases, and consider what an all-out consolidation would mean.

5. Don't forget that SharePoint is only one piece of the total puzzle. Your network, your geographical distribution, and other factors, need to play as large a role in your planning for SharePoint as they do with any other system in your enterprise.

6. Read for Microsoft's document on MOSS performance/capacity planning.

$200 Netbook reminder why

Its not much a secret that cost-cutting is a norm during recessions. The $200 Netbook (see is a reminder of that trend. And now we see IT organizations cutting costs on development (i.e. Java, C#, Cobol, C, VB, etc.) and packages (i.e. PeopleSoft, SAP, etc.) for lower cost alternatives such as cloud computing (i.e. everything on the server). However with concerns over security and all its legal implications they need a robust platform for cloud computing that's secure, auditable, feature-rich, agile and from a reliable vendor. And that's precisely why SharePoint and TFS are so hot right now. SharePoint is a full-service portal that can be customized with agility to do anything. TFS is the same for an IT organization striving to do the same for the business-at-large.

Wednesday, January 14, 2009

14 Very Useful SharePoint Links

Best Practices for Intranet Sites

See for the "10 Best Intranets of 2009". Its this year's results of a 9 year annual intranet design competition. Some tidbits I gleaned.

1. One of the strongest trends over the years is that intranet teams have been getting bigger. IMO Intranet teams are becoming the central administration and corporate communications departments for companies.

2. We're seeing a steady increase in user-centered design. Simple customization can often generate sizeable productivity wins. IMHO building web parts and user controls rather than just application pages is integral to this goal. Anything built for SharePoint ought to be plug-n-playable within user-customized pages that they'll be building for themselves.

3. To assess the ROI of intranet redesigns, teams primarily relied on usage metrics in terms of users, visits, or page views.

4. Collaboration features such as social networking, employee directories, CEO blogs and interactive forums are becoming vital. IMO the CEO doesn't write the blog. Its done by an Intranet team staff member who exchanges about 10 emails a day with the CEO's secretary who knows how to make emergency blog changes.

5. Many of the top intranets are built on a single intranet platform that integrates most of the supporting features they need.

6. Fully half of the winning intranets used SharePoint, especially the recent MOSS platform (Microsoft Office SharePoint Server 2007). As the following chart shows, SharePoint use has grown dramatically in recent years. This is particularly impressive given that, from 2003–2006, the winning intranets didn't use earlier versions of SharePoint at all. This may help explain why I get hundreds of emails from recruiters every week.

Get Started as a SharePoint Developer

At I found some good references on what to do to start becoming a master SharePoint developer that inspire this post:

(1) Do custom development for SharePoint on a Windows Server machine that has SharePoint and Visual Studio installed. You will regret trying it any other way this year. Download Virtual PC at and the VHD at

(2) Free Online Training – There’s lots of online training out there. Some of it free, some of it quite costly. One of the newer offerings is a Ramp Up course from Microsoft:

(3) Read BLOGs and do Twitter searches on SharePoint. See,,,, and

(4) Find good sample code. See or for plenty of SharePoint code samples.

(5) Stay current on SharePoint by going to to subscribe to this BLOG. If you don't have a RSS Reader then I suggest using as your reader.

Friday, January 2, 2009

Future Improvements on C# Code Commenting

Read to see a tutorial I wrote on what I consider to be the current "best practice" for C# Code Commenting. I have a few suggestions on future improvements to this "Best Practice":

(1) There should be a way to automate adding a post-build event for source code projects to have the Sandcastle CHM generated as part of the build.
(2) Certainly other project documentation (such as project charters, requirements documents, design/architecture documents, TFS reports (i.e. builds, work items, changesets, etc.) and other artifacts can be integrated into the post-build event.
(3) Certainly the whole post-build process done locally on auto-building the CHM file and including other artifacts can be included as part of the TFS Build process.
(4) Certainly templates with the HP logo, SLM-labels, and other process needs can be integrated into the help-files generation process.
(5) Considering that code comments are compiled into a XML file using a defined schema we can always customize the documentation however we want with XSLT, third party tools, etc.
(6) As Sandcastle is "open source" and Visual Studio is quite extensible it should be possible to specify custom XML tags that can be processed to generate whatever output or perform whatever tasks we want done at build-time.

Do you have any suggestions to add?

Best Practice on C# Code Commenting

For the next 30 minutes I recommend you do the following 7 steps. They'll teach you how to become proficient on a best practice for self-documenting your C# code in projects done using Microsoft Visual Studio. The same lessons apply for other .NET languages but I mention C# because its the most popular one. Once you've learned this process I'm confident you will use it for now on because it automates the documentation process for all development work to allow you to build HTML/Help files on-the-fly. Make sure you have Visual Studio 2005 or later installed on your workstation and that you've been able to successfully create and build a solution/project before proceeding with these steps.

(1) Read which is an excellent intro to C# Code Commenting.

(2) Read for a nice explanation on code commenting.

(3) Run Visual Studio, open a solution/project and follow the following instructions. (a) Open the property page for the project, usually by right-clicking on the project in the Solution Explorer, and click Properties. (b) After the dialog has opened, click the Configuration Properties folder. (c) Click the Build option. (d) In the right pane, there will be a property field called XML Documentation File. Set this to the path and file name of the desired file. The path entered is relative to the project directory, not absolute. (e) Put some "Hello World" text in a summary tag on at least one class/member within the project. (f) Build the project and view the XML Documentation File to see your "Hello World" text. (source:

(4) Download and install the product. If you skip this step then you will be very sorry.

(5) Go to, download the latest "Sandcastle Help File Builder Installer" MSI file and install. Then run it on your desktop start menu as follows: "All Programs -> Sandcastle Help File Builder". In the GUI click the ADD button to include the DLL file that corresponds with the assembly you generated in Step (3)(f) of this tutorial. Then select "Documentation -> Build Project" from the menu to build a Help file. Finally select "Documentation -> View Help File" from the menu to see the help file and search for your "Hello World" text.

(6) Read on recommended documentation tags and try them out in the project you used in Step 3. Build the project in Visual Studio. Then build the help file in Sandcastle to see the resulting help file.

(7) Read to see some other code commenting tools for .NET. However I recommend using Sandcastle because it has plenty of functionality, its source code is freely available at and a google search such as shows that there is sufficient documentation, assistance and community support for Sandcastle's future.

Did you do all 7 steps and bookmark this link for future reference? If so then you should now be sufficiently proficient enough on the current best practice for self-documenting your C# or VB.Net code in projects done using Microsoft Visual Studio. Congratulations Guru!! See for ideas on enhancing this best practice.

Thursday, January 1, 2009

More links for my personal research

The following is here for knowledge retention purposes only so be forewarned that it might bore you and you can stop reading now.

Today I've been doing plenty of blog-reading. There are many more things I'd like to read further but I'm out of time. Here are 5 links without notes and 2 links with notes.

The Greatest Invention in Computer Science is "The Routine"

Aside from the invention of the computer, the routine is arguably the single greatest invention in computer science. It makes programs easier to read and understand. It makes them smaller (imagine how much larger your code would be if you had to repeat the code for every call to a routine instead of invoking the routine). And it makes them faster (imagine how hard it would be to make performance improvements in similar code used in a dozen places rather than making all the performance improvements in one routine). In large part, routines are what make modern programming possible.

the problem with routines: they only take a minute to learn, but a lifetime to master ....

* How long should this routine be? How long is too long? How short is too short? When is code "too simple" to be in a routine?
* What parameters should be passed to this routine? What data structures or data types? In what order? How will they be used? Which will be modified as a result of the routine?
* What's a good name for this routine? Naming is hard. Really hard.
* How is this routine related to other nearby routines? Do they happen at the same time, or in the same order? Do they share common data? Do they really belong together? What order should they be in?
* How will I know if the code in this routine succeeded? Should it return a success or error code? How will exceptions, problems, and error conditions be handled?
* Should this routine even exist at all?

One thing I'll add is this. I LOVE STUBS. That's where I decide for a subroutine on a test value that will get sent back to the calling method until I have time to properly design/write the subroutine. My favorite phrase is "Hello World from ". For example a subroutine called MyNamespace.MyClass.MySubroutine will send back "Hello World from MyNamespace.MyClass.MySubroutine 001" the first time. As new test versions are built and the code gets improved I might increase the number so it now says "... 002", then "... 003", etc.

It is the job of a good software project manager to recognize the tell-tale symptoms of this classic mistake and address them head on before they derail the project. How? By forcingencouraging developers to create a detailed list of everything they need to do. And then breaking that list down into subitems. And then adding all the subitems they inevitably forgot because they didn't think that far ahead. Once you have all those items on a list, then -- and only then -- you can begin to estimate how long the work will take.

Until you've got at least the beginnings of a task list, any concept of scheduling is utter fantasy. A very pleasant fantasy, to be sure, but the real world can be extremely unforgiving to such dreams.

Johanna Rothman makes the same point in a recent email newsletter, and offers specific actions you can take to avoid being stuck 90% done:

1. List everything you need to do to finish the big chunk of work. I include any infrastructure work such as setting up branches in the source control system.

2. Estimate each item on that list. This initial estimate will help you see how long it might take to complete the entire task.

3. Now, look to see how long each item on that list will take to finish. If you have a task longer than one day, break that task into smaller pieces. Breaking larger tasks into these inch-pebbles is critical for escaping the 90% Done syndrome.

4. Determine a way to show visible status to anyone who's interested. If you're the person doing the work, what would you have to do to show your status to your manager? If you're the manager, what do you need to see? You might need to see lists of test cases or a demo or something else that shows you visible progress.

5. Since you've got one-day or smaller tasks, you can track your progress daily. I like to keep a chart or list of the tasks, my initial estimated end time and the actual end time for each task. This is especially important for you managers, so you can see if the person is being interrupted and therefore is multitasking.

Reading and Blogging in 2009

IMHO the year 2009 will be the year when the best-organized IT managers/professionals get themselves in the habit of well-managing their blog-reading and knowledge retention. The IT professionals in 2009 who are going to be leading the efforts in the industry to apply technology to real-world business needs are going to be doing plenty of reading in order to stay current, solve problems and come up with the best solutions for their organizations. Typically this will be done through an "in-the-cloud" RSS reader that's also installed on their mobile phone and allows them to analyze statistics and prioritize their RSS feeds to be more productive. They'll spend at least 10 hours/week reading blogs. It'll happen on the train, in restaurants or anywhere they're "waiting" on their mobile phones. It'll happen while they are using their computers at work or home. They will typically be following hundreds of blogs and add at least a dozen or more additional ones every month to their subscriptions. Next they'll track the statistics on their subscriptions and organize them according to which ones are most useful in their jobs/work and then focus on getting updates from the blogs that are the highest priority. In a typical week they'll glance at thousands of titles and then pick a few hundred of the titles to click on to see the opening sentence in the posting. Of these a couple dozen will actually be read and most of the rest just skimmed. With all the constant change in technology there is no more effective way to stay current on technology in 2009 than through fast-speed-blog-reading.

If you want to be heard then you need to earn trust and be rated high on their watch list. You can accomplish this by doing the following:

(1) Regularly update your blog with current useful content.
(2) Generally make each entry short and easy to read.
(3) Provide all possible links and references to avoid plagiarism.
(4) Its imperative that you sincerely try to be completely unbiased and objective.
(5) Warn your readers if you are going to write lengthy details for your own knowledge retention purposes.

Communication and Blogs

One thing I really like about TFS and Sharepoint is how they really work to improve collaboration, communication and using blogs out-of-the-box to disseminate information appropriately. I found a blogger at who provides some good tips that should help every IT professional.

The single most important thing you must do to improve your programming career is improve your ability to communicate.

To program, you must elicit ideas from other people and share your ideas with them. Sharing ideas comes in many forms: explaining how you did something. Suggesting a new practice for the team. Demonstrating how something works. Convincing everyone to switch programming languages. Persuading a brilliant engineer to join your team. Persuading your manager to get out of the way and let you do your thing.

Advancing your career is entirely about communicating. Getting a job. Turning down a job. Asking for a promotion. Turning down a promotion. Getting onto a good team. Politely extricating yourself from a good team. Persuading a brilliant engineer to co-found a company. Helping a brilliant engineer understand why co-founding a company isn’t the right thing to do. Asking for funding. Turning down funding. Getting clients. Turning down clients.

If you take just one thing from this post, let it be this: To improve your programming career, the single most important thing you must do is improve your ability to communicate your ideas face to face.

I learn:

Three types of great BLOG posts:
What I learned from Language X that makes me a better programmer when I use Language Y
Something surprising that you probably wouldn’t guess about Language X from reading blog posts
My personal transformation about Idea X

A type of timewasting BLOG post:
Here’s why such-and-such

Using Routines in Programming

The longer I code the more I've learned that the key to good programming is in how you approach writing routines. Steve McConnell at lists the following 8 reasons and I provide commentary.

  • Reducing complexity - I like to keep my routines short enough so I can read the routine declaration line to the bottom "}" all within one Visual Studio window. That's usually about 40 lines.

  • Avoiding duplicate code - I agree its the most popular reason for routines.

  • Limiting effects of changes - Doing the repeatable job in one place is important and that's why good requirements analysis and good software design/architecture up-front is essential in creating good coding practices.

  • Hiding sequences - This is why good routine-writing is essential to good object-oriented programming as its through hiding sequences in routines that we accomplish good encapsulation.

  • Improving performance - without good, organized routines you will never figure out where the bad-performing code is located

  • Hiding data structures and global data - good for encapsulating, sometimes bad for documenting the data structures' usage so that future DBA's and architects can read the code and make future changes or integrated systems.

  • Promoting code reuse and planning for a family of programs - This is where object-oriented programming provides real value with routines. And with the [obsolete] tag in C# and other code management tags & comment sections for .NET routines it makes it much easier to plan, document and validate code reuse or lack-of-reuse.

  • Improving readability - well-naming and keeping the size of the routine down to 20-40 lines is vital. Making routines too short or not designing the high-level algorithm well will cause what I call "sub of sub of sub of sub of sub ... I'm lost and can't find the code" syndrome. Basically its not easy to have too many nested levels of subroutines to dig through in order to find the code you need to work with and this is a common problem I run across when the subroutines are too short and the algorithm was either not well thought-out or its undergone considerable change.

  • Improving portability and isolating use of nonstandard language functions - interfaces and gateways from C# into COM libraries, external web services, external "C" code, etc. are well-managed through good routine writing.

  • Isolating complex operations - this is one of the greatest use of routines - any complex task must be done through ONE routine with calls to multiple subroutines in cases where alot of code is needed

VS2010 Planned Features and "Later" Features

for a list of planned features for Microsoft Visual Studio 2010 and some features planned for future features AFTER Visual Studio goes out.

For VS10:

* A new Windows Presentation Foundation-based (WPF) text editor
* More “modern,” with more of a WPF look and feel throughout the suite
* Smaller in size (in code and data) than Visual Studio 2008
* More reliable and modular

For some time “later”:

* Visual Studio Tools for Applications (VSTA) used for macros, plus other “end-user extensibility” improvements
* The ability to create more add-ins in managed code
* Full WPF shell
* Extensive support for the parallel framework for multicore hardware

Like just about every Microsoft product these days, VS 10 is going to get the Software+Services treatment ....

New Microsoft Programming Language Code-Named "D"

According to

A handful of Microsoft’s top developers are working to create a new programming language, code-named “D,” which will be at the heart of the Microsoft’s push toward more intuitive software modeling.

D is a key component of Microsoft’s Oslo software-oriented architecture (SOA) technology and strategy. Microsoft outlined in vague terms its plans and goals for Oslo in late fall 2007, hinting that the company had a new modeling language in the works, but offering no details on what it was or when the final version would be delivered.

D will be a declarative language aimed at non-developers, and will be based on eXtensible Application Markup Language (XAML), sources, who asked not to be named, said.

Sources close to Microsoft confirmed the existence of D, which they described as a forthcoming “textual modeling language.” In addition to D, sources said, Microsoft also is readying a comlementary editing tool, code-namd “Intellipad,” that will allow developers to create content for the Oslo repository under development by Microsoft.

5 Key Areas of Microsoft Oslo

See for the following on the “Oslo” advancements that will be delivered through Microsoft server and tools products in five key areas:

Server. Microsoft BizTalk Server “6” will continue to provide a core foundation for distributed and highly scalable SOA and BPM solutions, and deliver the capability to develop, manage and deploy composite applications.

Services. BizTalk Services “1” will offer a commercially supported release of Web-based services enabling hosted composite applications that cross organizational boundaries. This release will include advanced messaging, identity and workflow capabilities.

Framework. The Microsoft .NET Framework “4” release will further enable model-driven development with Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF).

Tools. New technology planned for Visual Studio “10” will make significant strides in end-to-end application life-cycle management through new tools for model-driven design of distributed applications.

Repository. There will also be investments in aligning the metadata repositories across the Server and Tools product sets. Microsoft System Center “5,” Visual Studio “10” and BizTalk Server “6” will utilize a repository technology for managing, versioning and deploying models.

David Chappell on Microsoft Oslo

See for the following:

Some Oslo details first went public in June of this year at TechEd. As described then, the code name "Oslo" applied to three things: a new version of Windows Workflow Foundation (WF), a server for running WF applications and others, and a set of modeling technologies, including a repository and visual editor. All of these technologies can be used together, so putting then under an umbrella code name made some sense.

Microsot Oslo and Visual Studio 2010

Planning a technology roadmap for the next few years requires that we know what's coming up from Microsoft with Oslo, Visual Studio 2010, etc. I'm not exactly sure how Oslo and VS 2010 will affect each other as Microsoft is wisely keeping all the details under wraps. I just know that their core functionality must be married as Oslo is the coding foundation for future Microsoft software code development and Visual Studio is the future tool for making it all happen. Stay tuned or be sorry!!

Suggested links: