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.