Archive for the ‘Automation’ Category
One of the really cool things about Feature Builder is that the guidance documentation also opens up inside VS and is available as you build extensions. However, this can also be limiting sometimes. If you want to just read through the material end to end to get a feel for the product or need a quick reference (or prefer a hardcopy) then the VS channel doesnt help.
Michael Lehman has provided an ‘offline’ documentation PDF which we have now made available at the Feature Builder Contrib workspace. Do note that this is a compilation of the guidance that unfolds inside VS so the hyperlinks wont work. This is just meant to be a ‘ready reference’ and not to replace the in-product guidance. We will try to update it for each release.
Check it out and send us feedback and also let us know what other content would be useful. As you use FB and FBContrib, if you would like to contribute any ‘User Notes’ (like the MSDN Community Content) with tips etc, then please do send that to us on the Contrib workspace and we will add it to the documentation.
Running the Experimental Instance from Command Line
Sometimes when running the experimental instance (for example when debugging a visual studio extension such as Feature Builder), the system throws error messages such as the error in following screenshot and asks us to run the application (that is, the experimental instance) on the command line with a “/log” parameter.
In order to run the experimental instance from the command line with the logging parameter, enter the following on a command prompt
|“C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe” /rootSuffix Exp /log|
This will then launch the instance and the log file will be populated. In general you are looking for information there that highlights if the extension clashes with another.
Completely resetting the Experimental Instance
In my case, while there were many ‘clashes’, it didn’t tell me what was specifically wrong. So, to fix this, I had to resort to Daniel Cazzulino’s post where he explains how to reset the experimental hive completely.
In case your Start menu doesn’t have a pinned option to “Reset the Experimental Hive” (mine didn’t), you can find it in the Start –> All Programs –> Visual Studio 2010 SDK –>Tools menu
Now when you launch the “rest Experimental hive” command line option, it will show the progress of initializing the experimental hive as shown in the screen below
As Daniel points out, when you first launch the experimental hive after that you need to manually enable the extensions in Extension Manager and after that it should work as normal.
One of the problems I had was that the experimental instance still had Feature Builder RC (0.9) installed so it refused to show me any of the new templates or my projects when debugging and this clean reset sorted the issue out.
Hope this helps if you run into issues with the experimental instance.
My first post for our MCS Solution Development Blog is now live and it’s on the topic of Feature Builder. This is the first in a series of posts in which we will go deep into the Feature Builder tooling and explore all that it offers for building Feature Extensions. I’ll link to the posts here on this blog but won’t cross post the same content, although i may post separate related content here.
Check it out and send me some feedback on the topics you’d like to see covered in this series. Also have a look at the ton of other great posts that my colleagues have been writing on everything from Azure to XAML (and all alphabets in between ).
I’m delighted to announce that MockingBird v2 has finally hit the RTM milestone. Whew! That was a long RC !
So, what’s new in this release ?
- First off, there’s a brand new Service Configurator module which makes it dead simple to create a mock service. Just pick a WSDL, click through a couple of menu options and it generates a complete service with all the default settings. You can then edit the config (manually) if you want to tweak the behavior further. Watch this space for enhancements to the tooling.
- The Service Studio app (of which the Configurator module is a part) has been completely rewritten and the GUI now employs the (free) Krypton Windows Forms Control Toolkit. That is simply an awesome piece of software and the fact that its free is mindblowing. I’m no GUI expert so any help in this area is a plus. I think you’ll agree that the new UI is way better than the old. (What’s that? you dont like it ? Hmm, if you know WPF/Silverlight, how about helping me write a better one? ) . Studio now is a full fledged management application for the Simulator. Tr
- Configuration has been given a complete overhaul. The config system no longer expects all config files to be siblings of the system config, which frees up the app to have centralized configuration (shared by the console host and the web application). I have even got rid of the EntLib config gunk from the app.config and kept it totally separate. I’ll write about all that separately. The next step in this is to externalize the WCF service and client config (which I know how to do but just havent had time) so again, watch this space.
- Tracing has now been added in so you can launch DebugView and happily monitor whats going on in the system. So you dont really need the log files (although you can always choose to use Log4net or EntLib additionally).
- Multi-Part WSDL support in the Configurator and the Message Instance Builder (formerly called WSDL Browser). Thanks to some cool metadata parsing code that Alex put into WSCFBlue and kindly allowed me to copy out, the system can now handle WSDLs on file and from any live service endpoint.
- Installation And Configuration is now made pretty much single click (3 clicks – 1 for each host and 1 for the studio) with a Powershell script to give permissions.
- RollUp of some functionality that the team put into the code-base post RC such as XsltResponse (to dynamically generate a response by applying XSLT to the request), a Soap Header aware message handler and various other fixes. The handlers now come with a proper MessageHandlerBase class so if you want to extend MockingBird with your own handlers, you can simply inherit from that and write your specific code.
Things to watch out for
- WSDLs are generally a minefield, so i wont claim that MB can handle any metadata you throw at it. It will choke on some WSDLs (notably Amazon web services) but under the covers I’m using stuff like MetadataExchangeClient and WsdlImporter from the core .NET framework so there’s not a lot I can do to handle weird WSDL. Anyway, if this is an area that gives you grief, let me know and we’ll see if we can start to support custom ‘import extensions’ like svcutil.
- Windows 7, 2008+ and IIS7.x : Limited time = limited test surface. I extensively tested on Windows Server 2003 R2 but not on anything else although the team does use Win 7 and Windows 2008 when they code MB features. I have included some notes on troubleshooting in the guide. The number 1 area that you are likely to fall a victim to (in IIS 7.x) is that the AppPool running MockingBird should be in Classic mode.
So, what’s next ?
- Some time to sleep I hope (although with baby no. 2 due shortly, that’s not going to happen is it?
- REST support
- Azure anyone?
- More in the configurator GUI
Sound appealing ? think you can help (except with the sleep !!) ? Let me know.
Just to call out that Edward Bakker is coordinating a new Contrib project for Feature Builder. This project provides more feature extensions such as Value Providers and Commands that can be added to an FB project. We are going to start looking into using Feature Builder for the next version of WSCF Blue.
If you are familiar with GAT/GAX and the pre-cursor to FB , Blueprints, do take a look at what we are doing in this new FBContrib project and send in your ideas and suggestions for more extensions. If you have some experience in these areas and would like to join and contribute, please let us know.
Just came across this great site with a collection of color schemes for Visual Studio 2010 and older versions too. There are some real beauties there. I quite like the retro look of Turbo-Pascal Revisited (though i doubt i could use it for a long time without drowning in the blue) and have started to use Desert-Ex Revised with a change of font to Consolas 12 point. Vibrant Ink is pretty good but can hurt the eyes with its brightness.
I also found that when you first run VS10, it asks if you want to import current settings from previous versions and then migrates those settings across nicely. I had been running Ragnorak Blue , one of Tomas Restrepo’s settings in VS2008 and that ported very nicely across. This StudioStyles site also has the VS10 version of Ragnorak Blue.
So if you like spicing up your coding experience with different color schemes, this site should have something for you. Enjoy.
Although BizTalk is in many respects ‘contract driven’ (with the emphasis on first setting up the XSDs for the messages etc), WSDL First development has, IMO, always been a bit ’iffy’. The purpose of this post is two-fold. One is to (re) start the discussion around Contract First development with BizTalk and the other is , through the discussion, to get a list of pain-points that I can go back to the product group with via our field channels and which would be of use to them in planning features for the next versions. I’m hoping that even if we cant get these into the core product, we could at least influence and/or help set up a CodePlex project to provide some of the missing ingedients.
In v2004 (and 2006 R1) absence of support for Contract First was a huge shortcoming because we couldnt even import a WSDL let alone round-trip it while maintaining fidelity to the original. With the advent of v2006 R2 and the WCF adapters, to some extent things are better. At least we can now consume WSDL or MEX endpoints.
However, Contract First isnt just about importing WSDL. The round-trip experience and being able to maintain fidelity to the original is critical, especially in interop scenarios. While we cannot always expect service consumption and publishing to be single-click / push button, IMO, there’s currently far too many steps involved in building a provider or consumer that adheres to a supplied WSDL (and this is assuming you manage to coax it into rendering the WSDL exactly as you want). Added to this, in the WCF world you also have to consider how you will handle strong typed SOAP Faults (when your client demands that you throw them). My esteemed colleague, Paolo Salvatori has a blog post describing how to add endpoint behaviors to a service to dynamically modify the WSDL exposed and to extend operations with fault messages. Ironically, I see this is part of the problem, namely, having to dive into so much custom code . Sure, its typical WCF, but hey, this is BizTalk, we are supposed to make the hard things easier.
The implementation of the tooling also leaves much to be desired. I don’t know of any people who still use Web Site projects as part of their automated build. Once the novelty wore off in the early days of VS2005, and once web apps came back in VS05 SP1, pretty much everyone went back to them. However, the Web Service and WCF Service publishing wizards still insist on generating website projects and there is no way to customize that to use your own template (has this changed in v2009 ?). While there is a command line tool to automate WCF service publishing, you cannot publish schemas as web services with that nor is there a command line interface (AFAIK) to automate consumption of WSDL/MEX endpoints.
Another problem I found is that Schema web services are great for one way messaging (especially when you can use direct binding so you dont have to tie an orchestration to the receive location) but if you want to expose a request/response operation, then you cant just use direct binding because the response doesnt make its way back to the required location. I read somewhere (could have been Yossi’s blog) that this is because the EPM demotes some properties. So you are forced back into an orchestration and static binding to the port. It’s not a big problem, after all the orch can be just a facade/shim, but it still feels a little dirty.
Ok, I hope that didnt come across as too much of a rant. I would like to hear your thoughts on the subject. Have I gone way off base anywhere ? Do you run up against the limitations of BTS in the Contract First (specifically WSDL First) world? What’s missing in the tooling? What should the product group (or a tool provider) be looking to supply to make things better. Do post your comments and let me know. Hopefully we can get enough consensus and ideas to provide the product group with valuable information. Let’s discuss.
I’m doing a little groundwork for the team that is now developing and maintaining the BizTalk LoadGen tool. The team is planning for vNext and we would like to know from BizTalk developers what your thoughts are on features/functionality that could be added on. This will be added to the planning list and depending on demand, priorities, budget etc (all the usual balancing factors) it may turn up in the next version.
I’ll get the ball rolling here. One of the things that people have asked for in the past is a UI to simplify adoption. Once you get familiar with the tool , the command line is all you need, which is the reason why the very early UI which you can see on a post by Richard Seroter was dropped. However, it may be useful to have some sort of UI to get people over the initial learning curve. But what kind of a UI should it be? The early UI was pretty much a simple property grid and a window to view the execution. Given that the XSD is available, it should be a simple matter for anyone writing a UI to plug a property grid that serializes out the XML. So is it worth the product team investing time in re-releasing a bog standard UI? How about wizards? Let me know and i’ll pass the info on.
BizUnit has LoadGen steps and the Performance Optimization Guide goes into a lot of detail on how to use BizUnit with LoadGen to test one of the BizTalk SDK end to end scenarios.
What other features would you like to see ? Do let me know via the comments on this post or the contact form and i’ll pass the requests on and keep you all updated.
A new Architecture power tool, the Feature Builder has been announced. This is the outcome of the earlier Blueprints project. As I had written earlier, in many ways Blueprints was the successor to GAT/GAX in terms of a platform for providing executable guidance inside Visual Studio and in its first incarnation was very much an ‘incubation project’.
To quote the introductory paragraph from the MSDN Channel 9 intro video page
“Feature Builder is an official Power Tool from the Architecture Tools team within the Visual Studio Product Group enabling the rapid construction of Visual Studio Extensions (VSIXs) that combine VS Extensibility (menus, etc.) , Project/Item/T4 templates and step-by-step guidance/documentation. The output VSIX, called a Feature Extension, delivers all these things, including the guidance, directly within Visual Studio”
The MSDN Forum for this tool is here and there is a FAQ posted by David Trowbridge, the architect on the project on this thread which explains what versions of VS are needed etc. There are a number of intro videos on Channel 9
All of this now builds on the architecture & modeling capability inside VS2010, so the tool itself cannot be run in a previous version (say VS2008) (I know it should be pretty obvious, but equally sure that someone still using VS2008 is going to ask this ). I guess if you attach code generation to the models that you build with this, then those could emit code for solutions in .NET 3.5.
Another question that is bound to come up now is “what happens to the old P&P software factories such as the Service Factory, Web Client SF and so on“. The P&P team have blogged about refreshing the factories for GAT/GAX 2010 and there is no public information yet on what impact, if any, this Feature Builder tool will have on those factories going forward, but as soon as I hear of any plans that can be disclosed, I’ll post a follow up.
Check out the tool and send the team feedback via the MSDN forum. I expect to dive in head first now and share what I learn here. Enjoy .
Beta-2 of WSCF.blue is now available.
The big feature of this new beta is the standalone Data Contract Generation and we have also put in some other fixes and addressed some outstanding issues (as well as rolling up fixes since the last beta).
The feature list is as follows. The “More Information” links point to posts on Alex’s blog with screenshots and lots of details.
- The Generate Data Contract Code feature is now available and supports the selection of multiple XSD/WSDL source files. (More Information)
- When the Enable WSDL Endpoint option is chosen a reference to the Thinktecture.ServiceModel.Extensions.Metadata.dll assembly is automatically added.
- Support for VB.NET has been added to the code generation.
- You can choose if operation methods on the service class will throw a NotImplementedException, call an implementation method in a partial class, or will be defined as abstract methods. (More Information)
- Force the SOAP actions (Action and ReplyAction) applied to each operation contract follow the standard WCF format: <namespace>/<service>/<operation>[Response]
Hope you find this release useful. As always , keep the feedback and suggestions rolling in. Enjoy