I hate to do this, but please can you re-subscribe to my blog using the following feed URL: http://bentaylor.org/atom.xml

I am migrating to different blogging software. In the process I have discovered that I no longer have access to my FeedBurner account. To make things worse, I no longer have access to the email account they have on record. There is no process to reset your account without this and there are many people in the "support" group that have received no help in this situation. Given that FeedBurner provides the RSS and Atom feeds for this blog, this is a problem. The only way I can see around this, is for you to re-subscribe. Hopefully I will see you all on the other side!

Autofac is an simple, elegant and powerful IoC container written by Nicholas Blumhardt, Rinat Abdullin and friends.  Version 1 was release in early 2008 and version 2 was released earlier this year with many newfeatures.  and If you are looking for an IoC container, I highly recommend it.

Autofac underwent some fairly significant surgery as part of the 2.x release in order to “simplify and streamline” usage.  The Autofac wiki lists the key changes for upgrading users.  Recently, I migrated a project from Autofac 1.4 to Autofac 2.2.  The changes were done in less than a day and so far we’ve not had any issues.  What follows are my “real world” notes on the changes I made. 

Changes Related to the Core Autofac Bits

• Updated component registration lifetime calls (see New Lifetime/Sharing Terminology):
  • FactoryScoped() to InstancePerDependency()
  • ContainerScoped() to InstancePerLifetimeScope()
  • SingletonScoped() to SingleInstance()
• Updated using statements for Module usages.  Module has moved from from Autofac.Builder to Autofac (see Namespace Changes).
• We were using the ComponentActivator delegate type in some custom extension method declarations.  We have changed these to Func<IComponentContext, TWeAreCreating> as the new Register overloads take this or a Func<IComponentContext, IEnumerable<Parameter>, TWeAreCreating>.
• Updated component registrations that require property injection.
  From this:
  ...As<IFoo>.OnActivating(ActivatingHandler.InjectProperties)
  To this:
  ...As<IFoo>.PropertiesAutowired(false)//false for no circular dependency.
• The Register methods now only accept delegates.  If you want to register an instance you need to use RegisterInstance.  While migrating to Autofac 2.2 this change highlighted at least one incorrect registration (see Separation of Registration Overloads).
• Removed calls to .MemberOf<IEnumerable<TWhatever>>() as resolving collections is supported by default (I know we could have registered the collection module in 1.x but we discovered a defect in it which Nick confirmed).  See Collection Support (“Resolve All”).
  • Removed custom extension methods for registering collections (.RegisterCollection<IFoo>) to using default collection behaviour.
• Updated OnActivating calls arg from EventHandler<ActivatingEventArgs> to Action<IActivatingEventArgs<TFoo>>.
• Named("RegistrationName") had been replaced by Named<T>("RegistrationName") as naming now requires type information too (see Changes to Named Services).

Changes Related to the Contrib and Integration Bits

• AutofacContrib.CommonServiceLocator - For some reason (I did it, but can't remember why) we had the source for AutofacServiceLocator in our project (this is an Autofac implementation of ServiceLocatorImplBase from the CommonServiceLocator project).  Deleted this (nice!) and added a reference to AutofacContrib.CommonServiceLocator.dll (taken from AutofacContrib).  Updated the construtor calls with RequestLifetime.
• AutofacContrib.Moq - Removed our AutoMockContainer implementation and moved to the AutoMock implementation in the Autofac.Contrib assembly AutofacContrib.Moq.dll.
  NOTE:  We had a lot of test dependencies on AutoMockContainer and the AutoMock type is quite different.  We found it easier to create an Adapter called AutoMockContainer that adapted AutoMock.
• Autofac.Integration.Web - The member IContainer IContainerProvider.RequestContainer has been replaced with ILifetimeScope IContainerProvider.RequestLifetime.  See the "Lifetime and Scope" section.

PlacedPrice is a property of a basket line item in the Commerce Server object model.  The name suggests (IMO) that it contains theprice of the item at the time the order was placed.  However, PlacedPrice actually contains the list price of the item at the time it was placed in the basket.  The property exists to track the list price of an item, so that if it changes during the lifetime of the basket the customer can be informed (if required).

How is the Placed Price Populated?

The PlacedPrice property is populated after you run a pipeline that contains the component RequiredItemAdjustPriceCy.  Pipeline components operate on IDictionary types rather than the CS object model.  Therefore, the RequiredItemAdjustPriceCy actually populates the cy_placed_price value of each line item dictionary.  If cy_placed_price is empty the value of cy_iadjust_current_price is copied into it.  Once you save the basket with populated cy_placed_price values the value is left untouched on future runs. 

RequiredItemAdjustPriceCy is configured in the the basket.pcf pipeline that is provided with the Starter Site and the other installed PUP sites.  Therefore, it is likely you have this component configure in your site.  The image below shows the component and describes it’s PlacedPrice behaviour:

The description text on this image is taken from the documentation for RequiredItemAdjustPriceCy.  Below are other excerpts relating to PlacedPrice taken from the Commerce Server 2007 documentation.

Additional Commerce Server Documentation on PlacePrice

• LineItem.PlacedPrice Property documentation:
  ”Gets or sets the unit price of the line item at the time it was added to an order group.”
• LineItems Table documentation:
  ”The unit price of the line item at the time that it was added to the order group.”
• RequiredItemAdjustPriceCy

The Commerce Server OrderDiscount pipeline component writes applicable discount information into the Order dictionary.  Specifically, it writes discount information into the item._itemlevel_discounts_applied  SimpleListand the _orderlevel_discounts_detail Dictionary/SimpleList.  The written information includes the property discount_timestamp which contains the last modified DateTime for the discount.  Curiously, it would appear that the values placed in these discount_timestamp properties are always one second later than the actual last modified DateTime value.  The correct value can be found in the dt_campaignitem_modified column of the mktg_campaign_item table (where the discounts and other campaign items are stored).

Is this a hack of some sort?  A mistake on my part?  A bug?  I have not done a detailed investigation (as that would be sad) so I don't really know the answer.

Filed under Commerce Server minutiae.  Do not read when operating heavy machinery as may cause drowsiness.