My good friend Carlos ran into a situation while working with one of his clients that seems to be triggering what looks like a bug in BizTalk Server 2010. The specific case came up when changing the Windows User Group associated with a BizTalk Host when that host is already associated as a Send Handler for an adapter.
Apparently, when doing the change, BizTalk will correctly update the information stored in the Enterprise Single Sign-On (ENTSSO) database (SSODB) for Receive Handlers, but not with Send Handlers, which leaves the system generating errors when the host later tries to access the SSODB to access the stored adapter settings.
Here’s the repro instructions:
ssodb.dbo.SSOX_ApplicationInfotable, you should see an entry associated with FILE_TL_BTTestHost, so that’s our newly created send handler. You’ll notice that the
ai_admin_group_namecolumn has the value ”BizTalk Application Users”, as expected.
SSOX_ApplicationInfotable again, you’ll notice that the row FILE_TL_BTTestHost still has the same value on the
ai_admin_group_namecolumn referencing the original group associated with the host, not the new group we assigned to it. This causes the access denied error for the host instance, because the host user is not considered to have access to the SSODB to read the adapter settings.
The ugly part is that working around this problem requires you to delete the original Send Handler and recreating it, which requires you to move all send ports already associated with it one by one.
Last week I was installing BizTalk Server 2010 on my development Virtual Machine, which previously had 2009 installed. Installation went fine, but when I started the BizTalk Configuration tool, it started hanging for minutes at a time.
Strangely enough, the tool let me configure Enterprise Single Sign-On (ENTSSO) without any problems, but would hang every time I tried to configure a new BizTalk Group. After some tests, it became obvious it was hanging when trying to connect to SQL Server to check if the group databases could be created until the connection timeout would expire.
It would indeed eventually respond again, but trying to do anything would only cause it to hang again. It was really weird that it would hang here because of the database connection, when the SQL Server used was local and ENTSSO had configured straight away without any problems.
Fortunately, I managed to figure it out: The problem was that the SQL Server instance had TCP/IP connectivity disabled (only shared memory was enabled). Enabling TCP/IP and restarting the SQL Server service fixed the problem.
I spent some time yesterday evening tracking down an issue with a custom WCF transport channel. This particular channel would support the IInputChannel channel shape, but with a twist: it would return a custom implementation of System.ServiceModel.Channels.Message instead of one of the built-in WCF implementations.
There’s nothing wrong with that and it was working just fine in most cases, until I ran into a few scenarios where the OnClose() method of my custom Message class wasn’t being called at all.
After some digging, I discovered that the specific messages this was happening to were not being processed normally by the ServiceHost infrastructure. In particular, they were not being dispatched because no method in the service contract matched the action in the messages, so instead the UnknownMessageReceived event in the ServiceHost instance was being raised.
Our UnknownMessageReceived implementation wasn’t closing messages explicitly, but that was easily corrected, so no problems, right? Wrong. Turns out, that it appears that in WCF 3.0/5 (haven’t checked 4.0 yet), if you do not have an event handler for UnknownMessageReceived, then the messages won’t get closed either.
This seems like a bad bug to me, because since Message implements IDisposable, there’s obviously the expectation that it will hold resources that should be released as soon as possible, so not calling
Closed() will leak resources and potentially cause trouble.
Attaching an event handler to UnknownMessageReceived just isn’t an option always, and even if it were, there’s no reason why WCF itself shouldn’t be guaranteeing that messages are closed as soon as they aren’t needed.
BetterXml is a Visual Studio 2010 extension I’ve been working on recently in an attempt to improve the experience of the built-in XML editor in VS. Right now it’s only on its early stages, so it doesn’t add much, but I hope to improve it as I find new things I’d like to add.
What does it do? BetterXml has two main features right now: Syntax highlighting extension and namespace tooltips.
BetterXml provides two new classification format definitions: XML Prefix and XML Closing Tag.
Here’s a screenshot showing both of these:
This is supported on regular XML documents (including XSD) as well as XAML and HTML documents.
If you hover the mouse pointer over a prefix in an XML document, BetterXml will try to figure out the URI of the namespace that prefix maps to, and present a tooltip with that information:
I haven’t done much tweaking of this feature yet so it will probably be a bit slow on large documents, since it requires partially parsing the document. This feature is only supported on XML and XAML documents.
I’ve been looking into other improvements I’d like to add to BetterXml. One I really wanted to provide was extending Intellisense completion based on previously used element/attribute names, which would be pretty useful for XML documents without schema.
VS2010 does provide ways to extend completion, and while it requires a lot of boilerplate code, it works. Unfortunately, after much trial and error I’ve been unable to make it work correctly, and certainly could never get it to behave the same way the built-in completion works.
While VS does seem to support multiple concurrent completion providers on the same buffer and will display the completion sets for all of them, I could not figure out the magic incantations to make it work reliably and in ways that behavior was predictable. Probably my own fault, but without clear documentation on how they are supposed to work together (if it’s even supported at all), it’s not trivial to do.
Source code for BetterXml is available as usual on github.
There are many .NET developers that can’t live without Jetbrain’s R# product. I’m not really one of them. Don’t get me wrong, I like the idea of R# and some of the features it offers, it’s just that it could be so much better if it didn’t keep getting in my way!
Let’s get something out of the way before I dive into what I’d like to see improved in R#: I bought my own R# license out of my own money. I do think it’s a fairly reasonably priced product for all the features it offers.
There are a few things that I can’t stand when using R#, however; to the point where I have to disable it just to get any work done without losing my mind:
Anyway, let’s see how life with R# 5.0 goes. So far, the VS2010 integration seems nice, but I will still be primarily a VS2008 user for a long time, so it sucks a lot that stability there hasn’t improved.
This is my first color scheme specifically created for Visual Studio 2010; I’m not likely to port it back to VS2005/2008 but I’m sure it would be possible if someone cared enough about it.
I started this color scheme on VS2008 but never completed it. When the Visual Studio 2010 betas started coming out, I imported it there and started tweaking it though a lot of revisions here and there as I used it. It’s been pretty much what I’ve been using for all my VS2010 development.
Download the most up to date .vssettings file for Metroline.
I only use WinDBG every once in a while, but, when I need it, I really need it and need it now. Kevin Dente pointed out earlier today that apparently, the latest versions of WinDBG was not available as a standalone installer, but only as part of the Windows Driver Kit ISO download.
That’s right. You now need to download a 620MB ISO, find a tool to open it up with (since Windows still lacks native support for opening ISO files directly) to extract a 17MB installer for WinDBG. From the WinDBG download page:
This current version of Debugging Tools for Windows is available as part of the Windows Driver Kit (WDK) release 7.1.0. To download the WDK and manually install Debugging Tools for Windows:
1. Download the WDK and burn the ISO to a DVD or other installation media. (The WDK ISO file is approximately 620 MB to download.)
2. Open the ISO from the installation media and open the Debuggers directory.
3. In the Debuggers directory, run the appropriate MSI or setup EXE for x86 and follow the instructions in the Setup Wizard.
4. After installation is complete, you can find the debugger shortcuts by clicking Start, pointing to All Programs, and then pointing to Debugging Tools for Windows (x86).
This really sounds awesome, on par with other MS utilities that get distributed as an MSI installer that installs an MSI installer that you can install. Yes, I’m being sarcastic.
Get it together, Microsoft; WinDBG is too important for support to screw it up like this.
It has been brought to my attention that a hotfix has been released for the BizTalk Server 2009 developer tools that should fix the problem I mentioned a few months ago with referencing WCF services within the same BizTalk project as the orchestration that uses them.
I haven’t tried it yet, but I thought someone might be interested in it.
I’ve been noticing some oddities in how Visual Studio 2010 RC handles Custom ClassificationFormatDefinitions when multiple extensions are interacting together. It it hasn’t been fixed already, then I guess it’s already too late for it to matter, but I still wanted to bring it up just to know if it’s just me that’s been noticing this.
As some readers are aware, I’ve written a couple of VS2010 extensions for myself which I always install as soon as I setup a new VS2010 installation, and so far I’ve been very happy with the results and VS2010 extensibility in general. Both of these extensions define custom ClassificationFormatDefinition, whose format I then tweak on my current VS color scheme.
And this generally works great. That is, until I install another extension created by someone else. The first time I noticed this was when I installed the Visual Studio Color Theme Editor extension by Matthew Johnson. Everything worked fine, except that after using it a bit I realized that every time I changed the color theme for the whole IDE using Matthew’s extension, my custom ClassificationFormatDefinitions would revert back to the default formats specified in the original definitions in code, instead of the values I had assigned to them in my customized VS color scheme.
Re-importing the .vssettings file with my saved VS color scheme would get colors and formats right again, so, to be honest, I didn’t give it much thought at the moment.
Yesterday, however, I ran into this again while trying VsVim by Jared Parsons. As soon as I fired up VS2010 after installing VsVim, I noticed that custom formats for my own definitions reverted once again to the default values. I ran into a couple of issues with VsVim so decided to disable it for now while until I had time to look into it closer and imagine my surprise when right after restarting VS2010 my customized format definitions came up right away instead of the default values!
So my impression is that something (but not sure what) causes VS to ignore customized custom definition formats configuration (confusing, I know, sorry) when multiple VS extensions are running. Has anyone else run into this before?