Have you had a chance to play
yet ?
Many folks have noted that a lot of the Visual Studio elements that have been present
within BizTalk to support the development experience are no longer…quite so BizTalk
specific! BizTalk projects now build upon C# projects, and thus a lot of the
differences that you used to see in navigating property pages, compilation settings
and build mechanics are now gone. This is a very good thing – it allows you
to leverage skills you already have on your team.
MSBuild support is now first class. Everyone who went through the trouble to
install (and invoke) DevEnv.exe on their build server in order to build BizTalk projects
will be glad to know that this is no longer required. (Builds can be ever so
much faster when you aren’t relying DevEnv…)
Because of the close relationship with C# projects, you can now have C# artifacts
directly in your BizTalk projects. Many people have noted that when you “Add
new item…”, C# classes aren’t offered as an option. The product group has
explained that this is because currently, the designers (such as the Orchestration
designer) are unable to provide intellisense for types that are within the same assembly.
So, you are required to use “Add existing item…”.
(This sort of reminds me of the interaction between
pipelines and schemas – the former require fullly qualified assembly information at
run time, which they won’t get if you combine these two artifacts in the same assembly.)
If this limitation persists, will the feature get used? I tend to think so.
There are often cases where the smart thing to do in an orchestration is to delegate
to a component…but the work you do in that component is, at times, so specific to
the orchestration that it makes sense for them to be co-located for deployment and
organizational purposes. What do you think ?
The support for unit testing is extremely welcome – check it out. Debugging
maps is great as well, but I’m now (often) partial to the external
XSLT approach these days.