Compilation Tests. Sql Server allows for SET NOEXEC ON, which compiles and checks many things for a batch of SQL commands, but doesn’t execute of it.  I have integration tests that run almost all my data layer code with NOEXEC ON and it reveals malformed parameter lists and other issues that would normally only show at runtime.  The tests run very fast, do not change the state of the system, and they don’t interfere with each other.  There isn’t anything to assert except that no exception was thrown.

Indempotent Tests. If your code has working transactions, then you create a root object (store), the child object (books in stock), etc as if the database was empty.  Then when you have enough objects to record a book sale, record the sale.  Assert something useful like numbers of rows affected, size of primary key etc.  Then roll it all back.

These tests can run fast, but might not depending on the particulars of the transaction.  For example, a stored procedure to calculate the payroll might be slow if the database has a 100,000 employees.  A good idempotent test will skip over any of these slow tests

Idempotent tests leave the database unchanged as long as your transaction code isn’t buggy.

Additive Integration Tests. Additive tests look a lot like the idempotent tests, except they don’t roll back.  Read world database code fails on account of how the data looks just as often as it fails for how the code works.  Not all code failures should be fixed by writing more code.  If common sense is violated by a column containing nulls 1% of the time, then it isn’t possible to write code to do something other than fail when that column is null.  But we can’t discover that our code and our data aren’t in harmony unless we run this test.

A good additive test is mostly inserts and driven by existing, real or highly realistic data.  An example would be taking the entire inventory of books and re-adding them with slightly different names.  If a row that exists now can’t be inserted with existing code, then one of them is wrong.

Additive tests leave the database modified, but because the transactions are mostly inserts, tests aren’t likely to be competing for the same rows and tables.  If performance characteristics warrant it, consider running it in a transaction and rolling back.  Better databases can rollback large numbers of transactions rapidly, worse database will take huge amounts of time to rollback or hang the server.

Destructive Integration Tests. Destructive tests operate on the existing data in a way to make it unsuable for other tests.  Destructive tests primarily do deletes and updates.  For example, if we imagine a test that looped through all books in inventory and recorded a sale, we might be able to discover some books fail to be sold when run through the sales code.  Either we have a code problem or a data problem and that is something we’d like to know.

At the end of the test, the database may be logically correct given the transactions you’ve run, but all the books have been sold, all the employees have been fired, all the book descriptions overwritten with lorem ipsum.  Like additive tests, these can be rolled back if your database can do so without performance problems.  Otherwise,  you will want to let these transactions commit and then restore the database from a backup.

Destructive tests are the least like unit tests and the most like the integration tests your unit test text book warned you about.

All of these proposed tests are, except the destructive ones, in my opinion, safe for putting in a build server nightly build.  Obviously none of these tests are safe for running on production and better integration testing is no substitute to refactoring, dependency inversion and writing true unit tests that are independent of the peculiarities of the persistent data store.

The Dec 2009 version lets Visual Studio 2010 run on 2 monitors, but not 3.

The July 2010 version will not let Visual Studio run on 2 monitors– you get constant flashing, disconnect-reconnect cycles (same as trying to take the Dec 2009 version to 3 monitors)

When rolling back, the old installer refused to run (claimed it was outdated) and you had to reset the system clock to get the install to complete.

Oh well.

The demo version is .12, but re-download seems to try to force you to get only the point version you originally bought, which is odd because the site seems to imply that you can get point updates for free within a major version.  I’m waiting for my phpBB credentials so I can ask on their support board.

Subversion vs VisualSVN.  Used AnkhSVN and checked in my code.  Installed WAMP. Found out that my windows home server for some reason had a PHP installation, so I had to update the environment variables to point to the WAMP installation.  I finally got VisualSVN to work with webSVN with windows auth.  It was tricky, required .conf file reading.  Using cygwin I got websvn working.

TeamCity.  Didn’t have to install Visual Studio, but did have to copy C:\program files\MSBUILD files.  It took an hour but now my unit tests and code coverage tools are all running.

Issue Tracker. Team City integrates with only 3 bugtrackers, of which only one is flat out free.  So I’ll be trying out Bugzilla, although several other bug trackers look more interesting.  Update: In frustruation, I gave up on Bugzilla because Perl is for people who enjoy configuration and installation pain and chewing on glass and poking their eyes with ballpoint pens.  I tried next the ruby and rails app “Warehouse”, but the @#$@#$ db scripts refused to run and I realized I didn’t have the patience to build my own inter-op doohicky for ruby to svn communication.  So on to mantis and flyspray.  Superficially, they’re closely matched.  But mantis has plugins and flyspray is more familiar to me because I’ve used it many times before.  So much work just to find out that free tools for developers often come with a heck-of-a installation burden.

Sharepoint homepage.  I’m still trying  to make WSS3.0 sharepoint useful.  So far only the link list is useful, but I may see about taking the RSS Feeds from everything above and creating a RSS reader in WSS3.0 to agregate my feeds which are essentially all intranet feeds.  If it frustrates me too much I’ll install a php base feed reader.

Before you break the build!
I’m aware of where you go
Each time you check in code
I watch my rss feed of the daily build
Knowing your code turns green dots red
But this time before you run the build
Making us do more work
(Think it over) Have you done a unit test or two ?
(Think it over) Is it refactored through ?

What I tried next was creating a set of Page and Control wrappers and factory functions. I called the add-in-side wrappers “Recipes” because they where recipes for building controls and recipes for building pages. The new contracts no longer had references to System.Web since no WebForms types there seem to be remotabe. In the hosting application I wrote a “Page Automator”, whose job was to implement recipes recommended by the Add-In and to describe the page for the Add-In by looping through the controls, putting their current state into a wrapper and then providing it to the Add-In.

Finally, out-of-AppDomain Add-In activiation works. And I was able to run the add in in minimal trust. If you’ve ever tried to get a non-trivial website to run under medium trust, you know this is just incredible! I gave up on medium trust because too many of my third party components didn’t play the medium trust way. In a medium trust website, everything in the AppDomain (i.e. the entire website) must refrain from calling forbidden APIs. As soon as there is a single line of code that requires Full-Trust and if you can’t remove it or change it (because it is both necessary and 3rd party closed source), you have to bump the entire website up to Full Trust. Unless you are using Add-Ins.

The plug in may need to communicate several things at once in the AddIn’s interface. System.AddIn makes this very, very hard. I tried string[]. I tried List. I tried IListContract. They all failed. When I used IListContract, the pipeline generator generated interfaces of type IList, and then the addin finder stopped finding addins that supported the contract. Humorously, string[] failed because System.AddIn said string[] wasn’t serializable. WTF? These are strings. I finally decided to use Control NextControl(); as a signature to return a collection one at a time. I finally did get IListContract to work, but the type of T needs to be remotable.

- Activation. A way to enable and disable plug ins at runtime
- Discovery. Plug ins are registered by scanning a directory for code artifacts.
- Code artifacts that implement an expected interface are used by the host application
- Plug ins are invoked with some sort of reflection
- Plug ins might need to run with fewer security rights than host code.

MAF/System.AddIn exists.
MEF is on the way,but it looks like it will be fully baked in .NET 4.0, no sign if it will support 3.5.

MEF is getting much more attention on the blog and the web and I attribute that entirely to the MEF team promoting their work more than the MAF team.

Benefits of MAF
Its a documented solution, that will always be better known and understood than any plug-in architecture you could throw together.
It is available in release form *now* and doesn’t require 4.0. MEF is pre-release and will require upgrading to 4.0 when it is release. (I think)

Challenges with MAF:
They team assumes you want version resilience. This is the most expensive feature. It achieves version resilience by adding 5 assemblies between your host and plug ins. Without code generation, the extra five assemblies adds too much work.

Also, when it comes time to write the V2 to V1 adapters, you will have to make ugly choices like, should the adapters throw errors or should they similate the new functionality. For example, in the calculator example where V1 supported adding and subtracting and V2 supported multiplication, you could have simulated multiplication by calling the V1 addition method in a loop to replicate multiplication. This would be better backwards compatibility, but now you got some business logic in your ViewAdapters. If you don’t put that logic there, then you will throw NotImplementedExceptions. Now how is a component backwards compatible if it throws runtime errors? (Well, admittedly the adapter lets the old plug in work as well as it used to just so long as you keep away from “new funcitonality” that arrived in V2)

They assume you need the extra security and reliability you get from loading plug ins in a sandbox. This means MAF wants you to declare contracts with primative datatypes if you can. Just like you can’t pass database connections or the HttpContext back and forth across a webservice, you aren’t supposed to do that in MAF (but you can, as long as you don’t load plug ins in a new AppDomain.)

Plug in UI. Officially, you aren’t supposed to pass winforms controls across MAF contracts, ie only the host has UI. WPF controls are supposed to be able to cross, ie. the plugin can have UI.

In ASP.NET, my own experimentation shows you can have server controls in the plug in, but it is hard beyond being worth it to put a Page or UserControl in a plug in and then get it to render on an ASP.NET page. This means that all ASP.NET plugins must mix code and UI more than I like. Some of this can be mitigated by the host providing enough extension points that it wouldn’t matter. For example, if a pluggable form page queried the plug in for the controls and used a host owned layout engine to layout the labels and input boxes, then the plug in writer wouldn’t have to mix too much presentation code and C#.

How does MAF relate to other similar ASP.NET technologies?
ASP.NET already can cope with new pages and classes being added at run time with minimal effect on the running application. A pattern I’ve seen is where V1 of the website is deployed, then when V2 is deployed, only the classes and pages that the developer thinks changed are copied into the V1 website. This creates a blended version V1/V2 website. If the contracts changed, e.g. a property of a webcontrol has a different data type, it is up to the developer to also track down the dependencies and deploy new versions of those too. Because pages are compiled on first request, the developer may not learn about broken contracts until long after the code in in production.

WebParts lets chunks of code and UI get plugged into or removed from a page at runtime. WebParts assume the webparts are being developed by the same team as the host, so the there isn’t necessarily any features for versioning, isolation or what have you. As a component technology, WebParts is all about a specific type of UI widget, where AddIns is *anything*, including things like adding an Icelandic spell checker to your website.

ASP.NET and process isolation.
ASP.NET and JSP and most other non CGI web technologies were created because spawning a new process for each request crushed server when they were under load. A common MAF recommendation is to design for the possibility of running your Add Ins in a separate process. But why would I want to constrain my design so that future developers will have the option of running a new process per page request and destroying the ability to support more than a few dozen concurrent requests? I’m convinced that a MAF addin running in ASP.NET should not take advantage of process isolation.

MAF and COM
It’s been noted that MAF has a lot of COM nostalgia. I think this is because MAF was created to solve the problems of creating Microsoft Office add ins. Microsoft office is a COM application and as such will work best with a component technology that has a lot of parallels with COM. This is a challenge for people like me because I never wrote C++ and don’t have an internal mental model of how COM works.

Some errors that happen:
Sometimes deleting the <property> section and readding it works. This happens all the time for all sorts of reasons, not just profile related, but dynamic compilation and shadow assembly related.

ProfileCommon not available- this is supposed to be compiled either at design time, run time or sometime. It fails to work in a variety of circumstances.

Precompiled apps can have problems with the ProfileBase class
Ambiguous reference errors- can happen when App_Code.Compiled or PrecompiledApp.config exist or fail to exist and ProfileCommon gets compiled twice.
Similarly copying the bin of the new version into the bin of the old is bad. You get a blended set of .dlls
Deleting files in ASP.NET Temporary Files sometimes works.

Interestingly, all the above don’t seem to be addressable by writing a custom provider. It doesn’t seem possible to override the settings part, where it reads web.config and starts trying to create that problematic ProfileCommon.

Conclusion
It turned out to be a dll that was referencing a native dll that wasn’t on the PATH. The profile was just triggering a compile. The compile then check references for everything in the \bin\ folder, even if the profile or invoked page isn’t using it. Oddly, this doesn’t happen on every single page, so there are some code paths where ASP.NET doesn’t feel the need to recompile every !@#$@!#$ thing in the world. This, I suppose is good or else we’d see pathalogical compile churning.

I diagnosed this by watching the list of assemblies that were getting loaded in Visual Studio while the debugger was attached. If it couldn’t load symbols or if it was obviously a COM dll, I considered it a candidate and finally narrowed it down to a SMO library, which happens to have non-managed dependencies.

If one tier is bad, two tiers is better, why not n tiers (or layers), I mean, literally an infinite number of tiers, each adding zero value along the way. I call this patter “Super Pipelining” Super pipelining makes dependency tracing a pain. A typial super-pipelined application will still put all authorization, validation, calculations in the UI and pass System.Data or SqlClient objects back and forth the super pipeline.


class Customer() {
public void AddCustomer(Dto customer){ (new CustomerBusinessObject()).AddCustomer(); }
}

class CustomerBusinessLogicDomainScenarioDatabasePersistenceObject() {
public void AddCustomer(Dto customer){ (new CustomerBusinessObject()).AddCustomer(); }
}


Ziggurat. A class that inherits from a class that inherits from a class that inherits from a class where the middle classes and the base don’t do anything. The classes in the middle do not magically make your code better.


class BusinessObject: BaseObject {}
class BaseObject: BasementObject{}
class BasementObject: UndergroundObject{}
class UndergroundObject: UbberBasementObject{}
class UbberBasementObject: SuperDuperBasementObject{}
class SuperDuperBasementObject: AceOfBaseObject{}
class AceOfBaseObject: China{}


System.TypeLoadException: Method ‘CreateObject’ in type ‘Microsoft.Practices.EnterpriseLibrary.Validation.Instrumentation.ValidationInstrumentationListenerCustomFactory’ from assembly ‘Microsoft.Practices.EnterpriseLibrary.Validation, Version=3.1.0.0, Culture=neutral, PublicKeyToken=21a151ab59c9591d’ does not have an implementation.

So if you get:


WebHost failed to process a request.
Sender Information: System.ServiceModel.Activation.HostedHttpRequestAsyncResult/63432468
Exception: System.ServiceModel.ServiceActivationException: The service '/Services/Astoria.svc' cannot be activated due to an exception during compilation. The exception message is: Service 'Astoria' implements multiple ServiceContract types, and no endpoints are defined in the configuration file. WebServiceHost can set up default endpoints, but only if the service implements only a single ServiceContract. Either change the service to only implement a single ServiceContract, or else define endpoints for the service explicitly in the configuration file.. ---> System.InvalidOperationException: Service 'Astoria' implements multiple ServiceContract types, and no endpoints are defined in the configuration file. WebServiceHost can set up default endpoints, but only if the service implements only a single ServiceContract. Either change the service to only implement a single ServiceContract, or else define endpoints for the service explicitly in the configuration file.
at System.ServiceModel.Web.WebServiceHost.AddAutomaticWebHttpBindingEndpoints(ServiceHost host, IDictionary`2 implementedContracts, String multipleContractsErrorMessage)
at System.ServiceModel.Web.WebServiceHost.OnOpening()
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.ActivateService(String normalizedVirtualPath)
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath)
--- End of inner exception stack trace ---
at System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Activation.HostedHttpRequestAsyncResult.End(IAsyncResult result)
Process Name: WebDev.WebServer
Process ID: 8168


This is what a connection string for an entity data model looks like. If you created your edmx file in a different project from your .svc file, you will need to manually copy the connection string. In this case I’m using Sqlite (which can’t be design using Visual Studio Express, in case you were wondering)


<connectionStrings>
<add name="calendarEm" connectionString="metadata=res://*/CalendarV1.csdl|res://*/CalendarV1.ssdl|res://*/CalendarV1.msl;provider=System.Data.SQLite;provider connection string="data source=C:\code\CommunityCalendar\Calendar\App_Data\calendar.db3;useutf16encoding=True"" providerName="System.Data.EntityClient" />
</connectionStrings>