sfeldman.NET
.NET, code, personal thoughts
-
AOP
I am looking at the code for Silverlight application and there’s something that just bugs me… INotifyPropertyChanged. This is not the first time, and yet again I see this interface implemented again, and again, and again. This violates several good principles (Single Responsibility and Duplicated Code). It also pollutes the code with cross cutting concerns (change notification). My choice of solution for this is simple – buy, do not build. Yes, it is possible to write a base class that would scan for a custom attribute and will do the wiring. But why? Why not to look into something like PostSharp and take advantage of the hard work the author(s) put into it to make it work.
-
Container for Silverlight
For most of our projects we use StructureMap as a Container. Silverlight seems to change this a little. From preliminary review looks like StructureMap is not yet ready for Silverlight, so we started to look into a different container. The one that looked good was Ninject. Simple, straight forward, and elegant.
-
Testing Challenge – Silverlight
I am getting involved in another project, that looks like has its own testing challenges (last project I was involved was a BizTalk based project, quite a few testing challenges!).
-
SVN Support for GitHub
This might be helpful for those that work with SVN and require (read-only for now) access to code that is under GitHub
-
Body Message Part Name in XLANGMessage
I was writing a custom component to copy message parts of an untyped message, invoked from orchestration. This message was created in a custom pipeline, and body part name had to have “Body”. For some bizarre reason, when message body part is handled outside of orchestration and passed into .NET code as XLANGMessage, body part name is “part”. ??? The other parts have the original names. I have no idea why this is happening, but thought it could save someone a question or two, especially when writing tests and expecting that the name of the part is “Body”.
-
Debugging BizTalk Orchestrations
Sometimes you have to get to the lower level of debugging (ie debugging auto-generated code) to understand what happens. This is what you can do to achieve it in BizTalk.
-
Multi-Part Message Parts Order
For the project I work on, processing involves multiple files. Files are packaged in a ZIP archive and it’s BizTalk application that opens the archive and builds a message for processing. In BizTalk terminology, this is a multi-part message.
-
Bizmonade – Testing Orchestration Receiving Any Document Type
I have posted before about Bizmonade testing library for BizTalk orchestrations testing. Unfortunately, there’s something something that looks like a limitation – testing orchestrations that receive any document type (System.Xml.XmlDocument). I posted a question on StackOverflow and curious to see if get anything at all. How do you test your general schema orchestrations?
-
Assembly in GAC and Configuration File
Working with BizTalk pushes the creativity sometimes. This time around, I needed to have an assembly deployed to GAC (so that BizTalk application can easily use it) and at the same time being able to configure this assembly without re-deploying it to GAC again.
-
Bizmonade
Bizmonade is a project allowing to simulate execution of BizTalk orchestrations without deployment to BizTalk server. What is it good for? Testing. Unit testing. The fact that the logic can be tested without deployment hassle is good. There are a few issues that I have encountered so far, and my experience with the particular tool is less than 24 hours (so excuse me in case I am not accurate – corrections are welcomed always):