While working on a Commerce Server 2009 solution, we were trying to create targeted advertisement only on the home page. We noticed that the Page group did not change anything. As it turns out, Microsoft has a fix for that. Here is the link:

http://support.microsoft.com/kb/968758

Tags: commerce server 2009

At least once in his career, a SharePoint developer is going to be faced with a security problem.

When a user executes an action in SharePoint, i.e. modifies an item in a list, the request on the server executes using the security context of the user. So, if the user does not have the right privileges to accomplish specific actions, the request could fail with a security exception.

A way to overcome this behaviour is to use the RunWithElevatedPrivileges method from the SPUtility class.

An important thing to keep in mind when using this method is the initial context of the object on which you will execute specific actions.

In the example below, even if you use the RunWithElevatedPrivileges method, the security context of the SPWeb object (web variable) is inherited from the user permissions.
This behaviour is normal because the SPSite site variable is a reference to the properties variable which was created with the user’s security context.

public override void ItemUpdated(SPItemEventProperties properties)
{
	SPSecurity.RunWithElevatedPrivileges(delegate(){
		using (SPSite site = properties.ListItem.Web.Site)
		{
			using (SPWeb web = site.RootWeb)
			{
				web.AllowUnsafeUpdates = true;
                                // Do some actions
			}
		}
	});
}

To run in a context with full control, all objects should be instantiated inside the RunWithElevatedPrivileges delegate method.
By doing this, objects will inherit their permission from the RunWithElevatedPrivileges context which is full control:

public override void ItemUpdated(SPItemEventProperties properties)
{
	SPSecurity.RunWithElevatedPrivileges(delegate(){
		using (SPSite site = new SPSite(properties.ListItem.Web.Site.ID))
		{
			using (SPWeb web = site.RootWeb)
			{
				web.AllowUnsafeUpdates = true;
                                // Do some actions
			}
		}
	});
}

Tags: sharepoint, .net, c#

To enable Windows Authentication in Firefox, to the following:

1. Open Firefox
2. Navigate to about:config
3. Edit the values of the following keys with the hostnames you want to enable.

- network.automatic-ntlm-auth.trusted-uris
- network.negotiate-auth.delegation-uris
- network.negotaite-auth.trusted-uris

Source: http://codebetter.com/blogs/eric.wise/archive/2006/11/16/Note-to-self_3A00_-Firefox-Windows-Authentication.aspx

Tags:

Yesterday, I encountered a strange error when I was developping a custom InfoPath enabling some cascading dropdown menus.

Here is the exception I had:

Unexpected end of file while parsing Name has occurred. Line 1, position 708. System.Xml.XmlException: Unexpected end of file while parsing Name has occurred. Line 1, position 708. [...]

After a lot of searches on the Internet, I'd found a very helpful post on the InfoPathDev forums.

To summarise, if the server on which you're developing is running with Windows SharePoint Services SP1 (Service Pack 1), your InfoPath form must not have a useless secondary Data Connection (declared but not used at all on your form).

By the way, if you're interesting to know how to implement cascading dropdown menus in an InfoPath Web based Form, take a look at the Cascading Dropdowns in Browser Forms article from the InfoPath Team Blog).

Tags:

Context

In most cases when someone write about the Decorator pattern it is usually related to UI stuff. The most common example is adding “decoration” to a control, for example a scroll bar. But in my humble opinion, this is not the most useful usage of Decorator. The purpose this pattern is:

“Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub classing for extending functionality”

Gang of Four

If you think about it, Validation is a responsibility and so it can be added by this pattern. Of course we can add the validation to the class itself or in its base class, but how would you reuse this validation across many unrelated objects and what if you object must derive from another base class?

Solution

The solution is the Decorator pattern. With this pattern we can add new responsibility to an object without changing its internals.

For simplicity purpose we will take a simple sample that anyone can understand but the concept shown here can apply to much more complex object.

Four our sample we will take a bank account. On this account we should be able to to money deposit and withdraw. The class diagram on the right illustrate this design.

Let’s start by defining our IAccount interface

namespace Model
{
    public interface IAccount {
        string AccountNumber { get; }
        decimal Balance { get; }
        bool Active { get; }
        void Deposit(decimal amount);
        void Withdraw(decimal amount);
        void Close();
    }
}

This simple interface will be the central abstraction of the system. The goal is to never depends on concrete class and this interface in enough to add a lot of functionality around an account.

Now here the interface implementation as an Account:

using System.Diagnostics;

namespace Model
{
    [DebuggerDisplay("Account = {_accountNumber}, Balance = {_balance}")]
    public class Account : IAccount
    {
        public string AccountNumber { get; private set; }
        public decimal Balance { get; private set; }
        public bool Active { get; set; }

        internal Account(string accountNumber, decimal balance)
        {
            AccountNumber = accountNumber;
            Balance = balance;
            Active = true;
        }

        public void Deposit(decimal amount)
        {
            if (OnBeforeDeposit())
                Balance += amount;
            OnAfterDeposit();
        }

        protected virtual bool OnBeforeDeposit()
        {
            return true;
        }

        protected virtual void OnAfterDeposit() { }

        public void Withdraw(decimal amount)
        {
            if (OnBeforeWithdraw())
                Balance -= amount;
            OnAfterWithdraw();
        }

        protected virtual bool OnBeforeWithdraw()
        {
            return true;
        }

        protected virtual void OnAfterWithdraw() { }

        public void Close()
        {
            if (OnBeforeClose())
                Active = false;
            OnAfterClose();
        }

        protected virtual bool OnBeforeClose()
        {
            return true;
        }

        protected virtual void OnAfterClose() { }
    }
}

If you expand the previous block of code you will see that the implementation of IAccount is only doing business stuff. There is no other responsibility in this class than the one that is meant for. We can clearly see “Template Method” design pattern here. All “OnSomething()” method are protected and any derided class can add implementation around the process. All “Before” method can cancel the process if the return value is false. This allow extension classes to add some specific behaviour.

But one of the main thing missing in this class is “validation”. We will use the decorator pattern to do that. A decorator class is a class thst implement all the member of an abstraction and forward all the calls to an internal instance of a real implementation that abstraction. In our case the abstraction is “IAccount” so we have to make a decorator that implement that interface.

namespace Model.Decorator
{
    public abstract class AccountDecorator : IAccount
    {
        private readonly IAccount _account;

        protected IAccount Account
        {
            get { return _account; }
        }

        protected AccountDecorator(IAccount account)
        {
            _account = account;
        }

        public string AccountNumber
        {
            get { return Account.AccountNumber; }
        }

        public decimal Balance
        {
            get { return Account.Balance; }
        }

        public bool Active
        {
            get { return Account.Active; }
        }

        public virtual void Deposit(decimal amount)
        {
            Account.Deposit(amount);
        }

        public virtual void Withdraw(decimal amount)
        {
            Account.Withdraw(amount);
        }

        public virtual void Close()
        {
            Account.Close();
        }
    }
}

As you can see the constructor of the decorator takes an instance of “IAccount”. All method forward their call to that instance. This base class simplifies the process of creating concrete decorator by allowing other decorator to implement some but not all members of the interface.

Now is the time to start implementing our validation class structure. For that purpose we will create a base validation class that will be responsible of applying the validation the IAccount instance.

using System.Collections.Generic;
using Model.Decorator;

namespace Model.Validator
{
    public abstract class AccountValidatorBase : AccountDecorator
    {
        protected abstract IEnumerable<IValidation> GetValidations(decimal amount);

        protected AccountValidatorBase(IAccount account) : base(account) {}

        protected void Validate(decimal amount)
        {
            foreach (var validation in GetValidations(amount))
                if (!validation.IsValid)
                    throw validation.Exception;
        }
    }
}

This simple base class define a “GetValidations” method that all derived class must override to add a list of validation to perform on method call.

Now to implement the “Deposit” validation we have to create this class:

using System.Collections.Generic;
using Model.Validation;

namespace Model.Validator
{
    public class AccountDepositValidator : AccountValidatorBase
    {
        public AccountDepositValidator(IAccount account) : base(account) {}

        protected override IEnumerable<IValidation> GetValidations(decimal amount)
        {
            return new List<IValidation>
            {
                new AmountGreaterThanZeroValidation(amount),
                new AmountShouldHaveOnlyTwoDecimals(amount),
                new AccountMustBeActiveValidation(Account),
                new DepositAmountNotExceedMaxValidation(Account, amount)
            };
        }

        public override void Deposit(decimal amount)
        {
            Validate(amount);
            Account.Deposit(amount);
        }
    }
}

This class is responsible for creating all validation instances. The “Deposit” method is overridden to call the base “Validate” method before doing the actual deposit.

To implement those validation we need to define the “IValidation” interface.

using System;

namespace Model.Validator
{
    public interface IValidation 
    {
        bool IsValid { get; }
        Exception Exception { get; }
    }
}

Here is a sample implementation:

using System;
using Model.Validator;

namespace Model.Validation
{
    public class AmountGreaterThanZeroValidation : IValidation
    {
        public AmountGreaterThanZeroValidation(decimal amount)
        {
            Amount = amount;
        }

        public decimal Amount { get; set; }

        public bool IsValid
        {
            get { return Amount > 0; }
        }

        public Exception Exception
        {
            get { return new ArgumentOutOfRangeException("amount", Amount, "Deposit amount should be greater than 0."); }
        }
    }
}

All other validations used in “AccountDepositValidator” can be described the same way.

The last step is to create an actual “IAccount” that will implement all this stuff. To do that we will need a Bank class. A bank is responsible of creating account. It will also be responsible of decorating it with all necessary decorators.

using System;
using System.Collections.Generic;
using Model.Logging;
using Model.Validator;

namespace Model
{
    public static class Bank
    {
        static readonly SortedDictionary<string, IAccount> _accounts = new SortedDictionary<string, IAccount>();
        private static int _accountSequence = 1;

        public static IAccount CreateAccount(decimal balance)
        {
            string accountNumber = String.Format("A{0:0000}", _accountSequence++);
            IAccount account = new Account(accountNumber, balance);
            account = new AccountDepositValidator(account);
            _accounts[account.AccountNumber] = account;
            return account;
        }
    }
}

To illustrate this process in action here is a sequence diagram:

1. Call Bank.CreateAccount.
2. The Bank instantiate an Account class.
3. The Bank create an AccountDepositValidator and wrap Account with it
4. The Bank return an instance of IAccount.
5. Deposit is called on IAccount which is an instance of AccountDepositValidator
6. AccountDepositValidator call Validate
7. AccountDepositValidator call GetValidations to retrieve the list of validation to evaluate
8. An AmountGreaterThaZeroValidation is created
9. IsValid returns true
10. AccountDepositValidator call base Deposit method
11. Balance value is updated

Next

With all this in place the only thing left to do is to implement all the other validators for all method of “IAccount”.

Tags:

Some of you who read my previous blog post notice that this technique doesn't allow to raise “PropertyChanged” event from a derived class. This is because you can only call method of “PropertyChangedEventHandler” from the class where it is defined. Anywhere else you can only assign (+=) and unassign (-=) event handler.

One way to work around this is to add a method in your base model class that will forward the call to “PropertyChangedEventHandler”.

Here is a modified copy of the class from my previous post:

public class Model : INotifyPropertyChanged
{
    private string _data;

    public string Data
    {
        get { return _data; }
        set
        {
            if (_data == value)
                return;

            _data = value;

            // Type safe raise from base method
            RaisePropertyChanged(() => Data);
        }
    }

    protected void RaisePropertyChanged(Expression<Func<object>> expression)
    {
        PropertyChanged.Raise(expression);   
    }

    #region Implementation of INotifyPropertyChanged

    public event PropertyChangedEventHandler PropertyChanged = null;

    #endregion
}

Now you can define a derived class and use the same method to raise a PropertyChanged event.

public class DerivedModel : Model
{
    private string _moreData;

    public string MoreData
    {
        get { return _moreData; }
        set
        {
            if (_moreData == value)
                return;

            _moreData = value;
            RaisePropertyChanged(() => MoreData);
        }
    }
}

Now with very little effort you can build a type-safe and bindable data model.

It is also useful to be able to raise many property at once. For example if have calculated properties that depends on others like in this sample class:

public class User : INotifyPropertyChanged
{
    private string _lastName;

    public string LastName
    {
        get { return _lastName; }
        set
        {
            if (_lastName == value)
                return;

            _lastName = value;
            RaisePropertyChanged(()=>LastName, ()=>FullName);
        }
    }

    private string _firstName;

    public string FirstName
    {
        get { return _firstName; }
        set
        {
            if (_firstName == value)
                return;

            _firstName = value;
            RaisePropertyChanged(() => FirstName, () => FullName);
        }
    }

    public string FullName
    {
        get { return String.Format("{0} {1}", _firstName, _lastName); }
    }

    public void RaisePropertyChanged(params Expression<Func<object>>[] expression)
    {
        PropertyChanged.Raise(expression);
    }

    #region Implementation of INotifyPropertyChanged

    public event PropertyChangedEventHandler PropertyChanged = null;

    #endregion
}

Because a change to either “FirstName” or “LastName” should trigger a change to “FullName” you have to raise both changes from both properties. Of course you can call “RaisePropertyChanged” many times but with a simple overload you can do this. All you have to do is add this to your extensions class.

public static void Raise(this PropertyChangedEventHandler handler, params Expression<Func<object>>[] proppertyExpressions)
{
    foreach (var expression in proppertyExpressions)
        Raise(handler, expression);
}

Aside from beeing type safe, this method will give you intellisense support while you type your “RaiePropertyChanged” calls. You still have to type the right property though.

Tags:

Implementation of the INotifyPropertyChanged interface is quite simple. There is only one event to implement. Take for example the following simple model class:

public class Model : INotifyPropertyChanged
{
    private string _data;

    public string Data
    {
        get { return _data; }
        set
        {
            if (_data == value)
                return;

            _data = value;

            // Type un-safe PropertyChanged raise 
            PropertyChanged(this, new PropertyChangedEventArgs("Data"));
        }
    }

    #region Implementation of INotifyPropertyChanged

    public event PropertyChangedEventHandler PropertyChanged = null;

    #endregion
}

This is a pretty standard way to implement a bindable property. The problem here is the “Data” string to specify which property changed. If someone change the name of the property without changing the content of the string, the code will compile fine but won’t work. In a big application with may properties it can be hard to detect and find the problem.

The best solution is to rely on the compiler to warn us. But because the property name is a string it can’t. So let’s change that line with a type-safe one.

public class Model : INotifyPropertyChanged
{
    private string _data;

    public string Data
    {
        get { return _data; }
        set
        {
            if (_data == value)
                return;

            _data = value;

            // Type safe PropertyChanged raise
            PropertyChanged.Raise(() => Data);
        }
    }

    #region Implementation of INotifyPropertyChanged

    public event PropertyChangedEventHandler PropertyChanged = null;

    #endregion
}

What is the trick? Raise is an extension method that takes a lambda expression to specify the name of the property in a type safe way. The Raise method resolve this expression to extract the name of the property and pass it to the PropertyChanged event.

public static class PropertyChangedExtensions
{
    public static void Raise(this PropertyChangedEventHandler handler, Expression<Func<object>> propertyExpression)
    {
        if (handler != null)
        {
            // Retreive lambda body
            var body = propertyExpression.Body as MemberExpression;
            if (body == null)
                throw new ArgumentException("'propertyExpression' should be a member expression");

            // Extract the right part (after "=>")
            var vmExpression = body.Expression as ConstantExpression;
            if (vmExpression == null)
                throw new ArgumentException("'propertyExpression' body should be a constant expression");

            // Create a reference to the calling object to pass it as the sender
            LambdaExpression vmlambda = Expression.Lambda(vmExpression);
            Delegate vmFunc = vmlambda.Compile();
            object vm = vmFunc.DynamicInvoke();

            // Extract the name of the property to raise a change on
            string propertyName = body.Member.Name;
            var e = new PropertyChangedEventArgs(propertyName);
            handler(vm, e);
        }
    }
}

All you have to do is to put this extension method in your code and the jib is done. Of course at the end a string will be used to raise the PropertyChanged event but because you don’t have to type it, you don’t have to maintain it.

Tags:

While building a new site with Commerce Server 2009 SharePoint services, we wanted to redesign the site and modify a lot of pages. The problem is that for us to do that 3 solutions were possible per Microsoft’s documentation:

1. Use the extensibility kit to edit the pages and master pages
2. Change the necessary pages directly in the Layouts folder of that SharePoint hive
3. Modify the pages in SharePoint designer

None of these solutions were suitable for our need and here are the reasons:

1. I do not recommend using the extensibility kit because we need to re-sign all the assemblies with a new key and change all references to the public key token. Also, if you modify the extensibility kit, you are making it very difficult to upgrade to future versions of CS 09, unless you only add web parts or pages. Finally, the extensibility kit does not include the contemporary site, which is the one we want to keep as a basis.
2. Changing the pages in the layouts folder is not a good idea because you basically change it for all of your sites. Of course it’s not an issue because usually there is only one CS site per machine. but still it can be an issue in a dev machine or if ever CS 09 should be used as Saas (Software as a service). Finally, this solution is not re-deployable.
3. Modifying the pages in SharePoint is also a plausible solution but again it is not deployable and it breaks the site definition.

So, what is the solution? It is to repackage the Contemporary site SharePoint solution and adding your custom features and modified pages. The following modifications were done in MOSS and not in WSS. I’m sure it is possible in WSS though. Also, for the packaging in wsp, I’m using WspBuilder.

So, here we go:

1. Un-pack the MicrosoftCommerceMOSSDefaultSiteV2.WSP file to any folder, let’s say “C:\ContemporarySite”. Your contents should look like this:

 

2. Now you need to restructure the features and files for WspBuilder. So essentially you would have:

Copy the following folders in 12\Templates\Features:

CommerceServerContemporarySiteCheckOutStepsInstance CommerceServerContemporarySiteImages CommerceServerContemporarySiteProvisioner CommerceServerContemporarySiteResourceDeployment CommerceServerContemporarySiteResources CommerceServerContemporarySiteSPListSampleData CommerceServerContemporarySiteXslts CommerceServerMyAccountSiteMapProvider

Copy the following folders in 12\Templates:

1033 CONTROLTEMPLATES IMAGES LAYOUTS SiteTemplates

Copy the following folder in 12:

Resources

Copy the following files in the GAC folder:

Microsoft.Commerce.Portal.ContemporarySite.dll Microsoft.Commerce.Portal.ContemporarySiteCommon.dll

 

Now that the basic structure is done, you are able to re-create the Contemporary site’s WSP solution and deploy it using Commerce Server SharePoint Services configurations tool. Before that though you will need to modify the SharePointCommerceServicesConfiguration.exe.config to take the new WSP file:

<sharePointSolutionGroup name="DefaultSiteAndWebPartsMoss" sharePointPlatform="moss" defaultInSilentMode="True">
            <sharePointSolutions>
                <sharePointSolution id="7b93b2ca-e1e4-4783-a038-14094933c002" file="MicrosoftCommerceWebParts.wsp" version="1.0.0.0" wspKey="1"/>
                <sharePointSolution id="Your solution ID Here" file="Your Solution Name Here.wsp" version="1.0.0.0" wspKey="2"/>
            </sharePointSolutions>
            <defaultWebApplicationSettings name="SharePoint - 8088" port="8088" extendedName="SharePoint - 8089" extendedPort="8089" appPoolId="SharePoint - Pool 8088" appPoolUser="domain\someone"/>
            <defaultSiteCollectionSettings create="True" title="Home" name="ContemporarySite" admin="domain\someone" template="MOSSCSContemporarySite"/>
            <defaultCommerceServerSiteSettings create="True" name="ContemporarySite" description="Commerce Server Site for Commerce SharePoint Contemporary Web Site" siteWithSampleData="False" databaseServer="."/>
</sharePointSolutionGroup>

 

Now you can use the configuration tool to deploy your site. Please be advised though that your MOSS environement needs to be clean because you are essentially redeploying the same feature as the contemporary site. Also, do not modify the name of the Contemporary Site’s site definition configuration names such as “MOSSCSContemporarySite” because the receivers look for those configurations.

In the next part of my post, I’ll show you how to modify the master pages and add new features to your site.

Tags: commerce server 2009, sharepoint 2007

Belgian MVP Releases SharePoint Tool Basket on CodePlex!

MVP Stéphane Eyskens recently produced a new SharePoint project on Codeplex called “SharePoint Tool Basket”. Within two months of launch, the project has appeared in the Top 10 list of the most popular Codeplex Sharepoint projects; the tool basket is proving very popular with the SharePoint community and has already been downloaded over 5,000 times!

This project aims to re-group a number of different SharePoint tools into one single container. The tool basket offers features such as SharePoint Document Rating, Form Designer, Ajax-enabled lookup field, Content Type Explorer, Feature Explorer and Audience to Group convertor.

If you have an interest in Microsoft SharePoint, the Tool Basket is well worth investigating.

Learn more about the project and download the project bits here.

Tags: sharepoint 2007

So… you downloaded PostSharp 1.0 and you installed it and are wondering… “What’s next?”.

Well my friends, let me walk you through the first steps of PostSharp. What could we do that would be simple enough? Hummm… what about writing to a debug window? That sounds simple enough! Let’s start. So I created a new Console Application project and I added the reference to PostSharp.Laos and PostSharp.Public. As a requirement, the class must be tagged with “Serializable” attribute and implement OnMethodBoundaryAspect (not in all case but let’s start small here).

Next, I have a few methods I can override. The two that we are interested in right now is “OnEnter” and “OnExit”. Inside of it, we’ll say which method we are entering and which one we are exiting. Here are my Guinea pig classes:

public class FooBar
{
    [DebugTracer]
    public void DoFoo()
    {
        Debug.WriteLine("Doing Foo");
    }

    [DebugTracer]
    public void DoBar()
    {
        Debug.WriteLine("Doing Bar");
    } 
}

[Serializable]
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Property)]
public class DebugTracer : OnMethodBoundaryAspect
{
    public override void OnEntry(MethodExecutionEventArgs eventArgs)
    {
        Debug.WriteLine(string.Format("Entering {0}", eventArgs.Method.Name));
    }

    public override void OnExit(MethodExecutionEventArgs eventArgs)
    {
        Debug.WriteLine(string.Format("Exiting {0}", eventArgs.Method.Name));
    }
}

See how simple this is? But… does it work? Let’s see the trace of calling each methods:

Entering DoFoo
Doing Foo
Exiting DoFoo
Entering DoBar
Doing Bar
Exiting DoBar

Isn’t that wonderful? Compile execute and enjoy. But… what about the community you say? Of course if the tool is not open source there is probably nothing built around it, right? Wrong!

Here is a few resources for PostSharp that include pre-made attributes that are ready to be used:

• ValidationAspect
• Auto-Implement INotifyPropertyChanged with Aspects (for use with Databindings)
• PostSharp4Entlib (Using Enterprise Library with PostSharp)
• Log4PostSharp (log4net with PostSharp)
• PostSharp4ViewState
• DesignByContract
• PostSharpAspNet (because ASP.NET use some post-processing and this plugin insert itself in the process to enable PostSharp)
• MicroContainer is a dependency injection container designed for .NET Micro Framework
• XPO Automatic Properties is for use with Express Persistent Objects by Developer Express

That was everything I could find. Do you know any others?

Tags: