Register for the Domain Driven Design that is platform-neutral and in fact, Eric gives .NET and Java versions of the courses.

More on Eric & DDD:
http://skillsmatter.com/course/design-architecture/domain-driven-design
http://skillsmatter.com/podcast/design-architecture/domain-driven-design
http://www.infoq.com/interviews/domain-driven-design-eric-evans

Also there are other limitations like time to wait for the server to timeout and time between clicks, which I am not sure the tool allowed them to adjust. Talking to them I recalled a tool for grabbing website thumbnails long time ago. one way for them would be to to make a batch file with it. The tool would grab the sites’ thumbnail and stress it, but they would still have to setup a number of clients. Also it creates and tears down an instance of IE every time, making it’s not optimal for that task.

So a couple of evenings later (and a few back-s and forth-s during the testing sessions) out comes SoakIE:

The app uses pretty much the same trick as the tool for grabbing website thumbnails but it does so in a nice UI and allows for some rudimentary settings for profiling the traffic:

You can select the number of IE instances that will do the clicking, you can select a minimum time between clicks – that is how often any IE instance can click (if it already finished with the previous request). this allows you to simulate clients that will stay a minute on your site and only click after they’ve read the page. Additionally if your application can on an occasion encounter a deadlock or a hang, it allows you to specify the maximum time to live of each request. If the request takes longer than the specified time, the application will “Stop” the request.

One thing that we’ve noticed though is that after a long time of soak tests the IE instances get mighty fat and start to slow down dramatically. Therefore I’ve added a maximum number of clicks an IE instance can perform after which the client will no longer recycle it for more click but will tear it down and create a new IE instance to continue testing.

Naturally the application needs to know what to test. This is specified in the “Test setup" tab in the “URLs to stress:" text box. The URLs will be picked in a round-robin fashion. The first browser will get the first url, the next one will get the second and so on, if the list will get exhausted the browsers will get fed it from beginning. You can theoretically put them in the box with some other text (like pasting it from a Skype window without stripping the message decoration around them) – SoakIE should be smart enough to parse the text and get the URLs out of it.

You can download SoakIE here

Well I have… and I’m sure I will. And so did Fredrikj on the our #epicode IRC channel ;).

Basically I had the tool that would convert from one language to another, but Fredrikj requested something that would switch master language of a page from one to another. Since I’ve already had some of the work done, I’ve updated the stored procedure I’ve written some time ago and slapped a nice GUI up on it. Here’s the result:

What the tool allows you to do is perform either language conversion or master branch switching on a selected page and all of its children (if you choose so).

The stored procedure have been updated to work on CMS5 R2 (will no longer work on R1 – but if you need that functionality, comment here or give me a shout and I’ll create a compatible version for you).

A word of caution though – I take no guarantee whatsoever about its operation. Especially, if you wreck your client’s database with it. I did what I could to prevent some of the obvious problems (like switching to a non existing master or converting to an existing one) but I will not be responsible if it won’t work for you. make a database backup and experiment there before you do any changes on the real data. That said – it works for me, so I think it should also work for you.

You can download the archive containing the tool here. unzip it to your EPiServer web application folder keeping the folder structure or the plugin reference will be wrong. Include the *.aspx and the *.cs files in your project and apply the SQL file to your database (The manipulation is performed by a stored procedure located in the file).

Also if you’re performing the change in a load balanced environment, you may need to restart the other servers once you do the changes. I reset the DataFactory cache, but I am not sure it propagates through to other servers.

The Wish List

Look for wireless networks more aggressively

Basically I find that very often I am still talking to the cell network when I could perfectly well be connected through a Wi-Fi. Turning Wi-Fi off and then back on again corrects the problem. This is annoying on a couple of levels. I have 3G turned off to conserve battery, It not noticing the Wi-Fi actually slows me down quite a bit, not to mention using up the precious data from the data plan (it’s only 500MB on the G1 plan in Poland)

Fix the battery problem

I mean really… 1 day is the best it can do when I do pretty much anything during the day with it. I could live with it being a little bit bigger if I didn’t have to fear it will die on me before the evening. I realize that this is because we have background apps, but perhaps you can introduce a CPU throttle technique that will slow down the operation when the horse power is not really needed. Perhaps something the next gen hardware will have to address.

Allow me to have multiple identities

The first thing you do when you start the phone is linking it to a Google account. That provides you with a really nice integration of Google calendar, mail & contacts. And it’s not just setting up apps for it. The whole system is aware of your identity and any app that wants to (and that you allow it to), might use them as a service. For example, a to-do list is able to schedule events in your Google calendar and setup mail notifications and send over mail invites your contacts to a meeting. It can reserve a time in your calendar for shopping that your wife has asked you to do. that’s great but… why is my phone fixed to a single Google identity? And yes, I realize that I can send email to and from multiple mail accounts and access other calendars through the browser. That’s not the point. I want BE adam.najmanowicz AT cognifide.com when I’m at work and BE adam AT najmanowicz.com when I’m leaving the office. I have a perfectly fine 8GB card sitting idle in it that could easily store a number of identities and swap between them. I want to be able to manage multiple calendars conveniently and have applications like to-do lists tied to them. Come on Google, even Windows 95 could do it! Introduce multiple profiles with easy switch!

Application uninstallation directly from the App drawer

Android Marketplace is a great repository that you can get plethora of apps quickly. It’s a blessing… and a curse. It’s a major pain in the rare to hunt the apps that you want to remove on the mile long list of apps that additionally re-populates after every uninstall without keeping track of where you left off while removing the previous app.
In the perfect word I could long-tap an icon and additionally to dragging it to the desktop I could drag it to some uninstaller corner.

The “Must haves”

That’s as much for anyone else as it is for my reference should I need to reset the phone to factory settings.

DroidWiki

A wiki like notepad. Supporting some basic wiki mark-up and links between notes. Brilliant idea, great implementation, perfect placement for a wiki!

Useful switches

This is what you will use to turn your Wi-Fi off and on again when it will fail to connect to the Wi-Fi again.

Astrid

Versatile and powerful, yet simple and elegant to-do list

Skype (Beta)

Naturally if you are using the Skype network. This is a native and group chat supporting Skype client.

Twidroid

So far my client of choice for Twitter. This is indispensible if you’re a part of the twitter craze.

The weather channel

Weather channel gizmo that allows you to check the weather for any area in the world at any time.

ConvertAll

Convert any unit to another.

Tricorder

For the geek cred.

Conclusion

Again, I need to reiterate, this is the best phone I’ve ever had. Having a full physical QWERTY keyboard and a browser with me all the time has definitely changed my life. I’m much more organized. I can track stuff much better and I have my priority list and my schedule always with me accessible from web as well as from the phone. The integration with Google apps is a tremendous selling point and none of the issues is a real deal breaker for me. Yet, this is the stuff that I will look up to in the following system releases.

• You may want to keep all of the files in one store – being forced to put them into a designated folder is not desired.
• You may want to make some file freely available for some time and lock it after a while, or the other way around (e.g. to allow the robots to crawl it initially). having to move them is just silly and defeats the purpose.

So how do you discriminate the files that you want locked from those that you want to be publically available, and potentially from those that you want only the logged in users to be able to get?

Specifying the EPiServer File Metadata sweetness

One of the potential solutions would be to define a special rights group and check for that group for the people that have your “registered” magic-cookie. That however introduces a bogus group, and I would rather like to avoid that. However if you look into the FileSummary.config file that’s located in your web application folder you will find a slightly mysterious content. A bit of hacking reveals that you can actually add your own metadata to the file. For example adding the access rights based on what I’ve established above would look as follows (the content you can already find in the file that comes with the public templates that-we-all-oh-so-love is skipped):

<root xmlns:xforms="http://www.w3.org/2002/xforms" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <model>
    <instance>
      ...
      <AccessLevel />
    </instance>
  </model>

  ...
  <xforms:select1 appearance="full" 
                  ref="AccessLevel" id="id_field51">
    <xforms:item>
      <xforms:label>Unrestricted</xforms:label>
      <xforms:value>Unrestricted</xforms:value>
    </xforms:item>
    <xforms:item>
      <xforms:label>Requires Registration</xforms:label>
      <xforms:value>RequireRegistration</xforms:value>
    </xforms:item>
    <xforms:item>
      <xforms:label>Requires CMS Login</xforms:label>
      <xforms:value>LoggedUserAccess</xforms:value>
    </xforms:item>
  </xforms:select1>
  ...

</root>

Great. So what does it look in the file manager now?

Splendid!

Accessing the metadata

Now that we gave the user to specify the metadata, we need the VPP to act upon them. For the benefit of automation of parsing I’ve specified the enum defining the access levels as follows:

enum FileAccessLevel
{
    Unrestricted,
    RequireRegistration,
    LoggedUserAccess
}

Now we need to update the GetFile method to discriminate the access levels (I have decorated the core lines with –>) those are the lines that access the meta data based on their format specified in the FileSummary.config.

public override VirtualFile GetFile(string virtualPath)
{
    string handledPath;

    if (TryGetHandledAbsolutePath(virtualPath, out handledPath))
    {
        UnifiedFile file = base.GetFile(virtualPath) as UnifiedFile;

        if (file != null)
        {
            string strAccessLevel = (string) file.Summary.Dictionary["AccessLevel"] ??
                                    FileAccessLevel.RequireRegistration.ToString();
            FileAccessLevel accessLevel = (FileAccessLevel) Enum.Parse(typeof (FileAccessLevel), strAccessLevel);

            bool isLoggedIn = HttpContext.Current.Profile != null && !HttpContext.Current.Profile.IsAnonymous;
            bool isRegistered = HttpContext.Current.Request.Cookies.AllKeys.Contains(PASS_COOKIE_NAME);
            string email = isRegistered ? HttpContext.Current.Request.Cookies[PASS_COOKIE_NAME].Value :
                (isLoggedIn ? HttpContext.Current.Profile.UserName : "unregistered");

            switch (accessLevel)
            {
                case (FileAccessLevel.Unrestricted):
                    return file;
                    break;
                case(FileAccessLevel.RequireRegistration):
                    if (!isRegistered && ! isLoggedIn)
                    {
                        HttpContext.Current.Response.Redirect(
                            string.Format(registrationFormUrl,
                                          HttpContext.Current.Server.HtmlEncode(virtualPath)));
                        return null;
                    }
                    return file;
                    break;
                case(FileAccessLevel.LoggedUserAccess):
                    if (isLoggedIn)
                    {
                        return file;
                    }
                    return null;
                    break;
                default:
                    return file;
            }
        }
    }
    return Previous.GetFile(virtualPath);
}

Now the user is really in control of what is published to the general public and robots, what is protected with the registration form and what is only available to logged in users. (now you may add more granularity with file rights naturally, this is just a basic setting that an editor without administrative rights can add.

Yet a full fledged registration doesn’t seem like a proper thing to do – cluttering your EPiServer user repository with (let’s face it – for a large part fake or temporary email addresses that user create only to get your content).

While there may be a lot of ways to handle that (streaming it through a page Response.WriteFile might seem as one of the more obvious ones), I would like to show you a cleaner, simpler and more elegant way that I’ve come up with.

We really don’t want people to deep link to our files without them knowing the files are from our site, that’s just rude – so hiding them behind an obscure URL wouldn’t work (thus we cannot use the regular file providers). We’ve already establish that we don’t want to log them in, so setting file rights are useless. But I want all the benefits including client-side caching.

Basically the solution boils down to creating a thin layer over the File provider of our choice, in my case the versioning file provider. The only method we need to override in it is GetFile. I want to allow downloading for logged in users and I want to allow downloading for all users that have a “magic-cookie” set. If either of the conditions are met, the file just downloads using the underlying provider’s routines including all the logic EPiServer has put for caching and rights. But if neither of the requirements are met, the user is directed to a page of our choice.

public override VirtualFile GetFile(string virtualPath)
{
    string handledPath;

    if (TryGetHandledAbsolutePath(virtualPath, out handledPath))
    {
        if ((HttpContext.Current.Profile != null && !HttpContext.Current.Profile.IsAnonymous) ||
            HttpContext.Current.Request.Cookies.AllKeys.Contains(PASS_COOKIE_NAME))
        {
            return base.GetFile(virtualPath);
        }

        HttpContext.Current.Response.Redirect(
            string.Format(registrationFormUrl,HttpContext.Current.Server.HtmlEncode(virtualPath)));
        return null;
    }
    return Previous.GetFile(virtualPath);
}

How you specify that page’s totally up to you, but there is a nice initialization routine called during the Virtual Path Provider loading phase where all of the settings that are specified in your relevant web.config VPP declaration are passed to you, why not use it? What you’ll need define your VPP in the web.config is what follows:

<add showInFileManager="true" virtualName="CookieEnabled" virtualPath="~/CookieEnabled/" 
     bypassAccessCheck="false" name="CookieEnabled" 
     type="Cognifide.EPiServer.CookieEnabledVirtualPathProvider.CookieEnabledVirtualPathProvider,Cognifide.EPiServer.CookieEnabledVirtualPathProvider" 
     indexingServiceCatalog="Web" physicalPath="C:\vpp\Resources" 
     RegistrationFormUrl="/File-Asset-Request-Form/?filepath={0}" />

you can then define your class as:

public class CookieEnabledVirtualPathProvider : VirtualPathVersioningProvider
{
    private const string REGISTRATION_FORM_URL_WEB_CONFIG_PARAM_NAME = "RegistrationFormUrl";
    public const string PASS_COOKIE_NAME = "ResourcePass";
    private string registrationFormUrl;

    public CookieEnabledVirtualPathProvider(string name, NameValueCollection configParameters) :
        base(name, configParameters)
    {
        registrationFormUrl = configParameters[REGISTRATION_FORM_URL_WEB_CONFIG_PARAM_NAME];
    }

    ...

}

So we know now where we want to direct people without a “magic-cookie” who want to get our assets, and how to do it, but how do we finally allow that file to get down to them?

In your page – for the same of simplicity I assume you will be using XForms for gathering the user data, but that really does not matter. When you validate the form data (or get the user to click on a link that you’ve sent them) you just set the “magic” cookie that I called “ResourcePass” to any value and to to expire in some a long amount of time, like a year. So that they can now access your files unrestrained and direct them BACK at the URL they came from – and now the VPP will allow them to just download the file they initially requested:

protected void XForm_BeforeSubmitPostedData(object sender, SaveFormDataEventArgs e)
{
    if (!Page.IsValid)
    {
        e.CancelSubmit = true;
    }
    else
    {
        string requestedFile = Request.Params["filepath"];
        HttpCookie cookie = new HttpCookie(CookieEnabledVirtualPathProvider.PASS_COOKIE_NAME, "true");
        cookie.Expires = DateTime.Now.AddYears(1);
        cookie.HttpOnly = true;
        Response.Cookies.Add(cookie);
        if (!string.IsNullOrEmpty(requestedFile))
        {
            Response.Redirect(requestedFile);
        }
    }
}

It’s incredibly convenient:

And fairly deadly to the merged contact. Once those contacts are merged and you save them but later try to come back to them to re-edit, I’ve noticed that whenever I select them for editing after that, they don’t pop up for the task, but instead the previously selected contact is being opened for editing. I can see the details of such contact, it synchronizes with the phone perfectly, just the editing won’t work.

Browsing through gmail support groups I’ve found out that a lot of people have this problem but somewhat it eludes Google. People suggest that clearing up cookies or history worked for them. No luck here.

What did the trick though was exporting all of them to the Google CSV:

Deleting all the contacts and then importing them back. Unfortunately once you do that all the associations they’ve had with the groups that youv’e defined are gone, but at least you can edit them again!

Well, not really. By default the framework will be run in the “legacy mode”. Thanks to an old article by our own Marek Blotny, I’ve learned how to build Plugin settings which are just perfect for the purpose!

So to configure and enable the new features you need to open your admin UI and in the “Config” click on the “Plugin Manager” item and select our framework plugin as shown in the picture

The available options are:

Setting Name	Meaning	Sample
Default WebParts Path Pattern	The pattern to be used when no pattern is defined for a page.	%inherit%
WebParts Path Patterns	The semicolon separated pairs of pattern;pattern name; This is the part you will want to customize most.	%template%|%pageid%%legacyregion%;Legacy regionalized;%template%|%pageid%;Legacy globalized;page|%pageid%|%region%;Page/region;pagetype|%pagetypeid%;Page Type
Cache WebParts in Memory	Determines whether the WebParts are to be cached  between usages (this is useful for a small set of WebParts (like a number of sidebars) but rather discouraged if you use the legacy mode as there can be a lot of those in such case.	unchecked by default (check to improve performance in sidebar mode)
Legacy WebParts Support (per-page only)	If checked, disables the extensions described by this blog.	checked by default (uncheck to enable the sidebar extensions)

As shown here:

Once you fill in the settings as they are suggested in the above table the context menu (or adjust to your needs) will show you the new options:

The new sub menu will allow you to change the pattern by which the WebParts are selected, while “Edit Web Parts” option will enable you to edit the WebParts for the current effective WebPart set.

First of all – if you want to select a pattern on a page you need a means of storing it. At this moment The framework does it in a property. Which means – for every page type that wants to redefine the web parts rather than using the default pattern (in our case %inherited%) you need to add String property with a “WebPartsPath” name (I may actually add some routines to add the property definition automatically if there will be enough demand for that).

What does “Effective WebPart Set” mean?

Assuming (which is the most interesting scenario) that %inherit% is the default pattern the following is true:

Once you select the effective web parts for the page or just agree with the WebParts pre-selected for you based on the default path you can edit them just like previously. Mind that when you edit WebParts on a page all the pages that have the same “effective path” are going to change as well. (which was our intention in the first place).

The library extension is going to be posted on Epicode as soon as I get a hold of Steve to approve the changes :)

Hmm…

Is sidebar a part of content? No, rather not. We don’t want the editors to have to setup the sidebar for every article they write (and the site has a few dozens of articles created on it every day).

Is sidebar more of a template thing? Well… more like it, but still… we have articles all over the site with different sidebar elements when the articles are in different parts of the site (ok so we could add rules what controls display in which part of the site). But wait! There’s more! The sidebar will be different for every language (region). Now we’re talking a dozen of templates or a rules engine just to make the sidebar different. Customising the template with properties isn’t ideal either as it makes EPiServer UI very cluttered. Additionally we want to change sidebars across many templates so the whole branch/section of the site will be able to share the same sidebar.

To a degree this is an academic discussion as we’ve been through it with the previous version of the site and we already knew that integrating this stuff into templates just won’t work and we will be in a world of pain just changing the templates over and over adding little tweaks and changes while the customer ads promotions and performs ad campaigns. Well, we can do it, of course, but it’s not a work a programmer will enjoy, and we all want to do new and more exciting things, don’t we?

We have an internally developed  module to make something like that, that is fully home-grown by another internal team (we now have 3 “squads” capable or making incredible things with EPiServer and we tend to share a lot of technologies and try to rotate people around to adopt the good habits and experiences) and I was (and still am) VERY impressed by it. The technology uses EPiServer pages for defining every module (which are located somewhere outside the site root branch. and then you can mix and match them either declaratively in the code) or by handpicking them in the UI. It’s really cool, though, during the discussions it turned out that we might have to add big chunks of functionality and might end up with separate branches of module-pages for different languages/regions, but… frankly… about that time an article by Ted Nyberg reminded me about a technology I have read about quite a while ago in an article by Stein-Viggo Grenersen and ooohhhhhh… I got seduced. I really wanted to try if for a long time and Ted’s article made it a snap to try and get convinced, and more important… convince Stu ;) that it’s the right way to explore.

So I started to dig.

Talked with Steve (the original creator of the Framework) a bit and learned that I can “customize a path rewriter” to suit my needs. Great! I just hoped I won’t have to deal with some nasty GUID’s matching, but no! Turns out, all it takes to identify a WebPart set is to have any unique string naming it.

So basically what we needed was a manager to deal with the naming templates and a way to determine the WebParts set to be used per page.

Till now the framework used template file name followed by the page ID, followed by an eventual language/region if a page was not the master branch, for example:

~/templates/Demo/WebPartPage.aspx|26
~/templates/Demo/WebPartPage.aspx|26|en-us

which makes them unique per page, which is not as appealing when you use EPiServer as it for a big part duplicates its functionality. Also a bit of a caveat here for agile programming methodology which promotes an often and early refactoring – if you move your page around or change its name – you lose the WebParts for all pages using it.

What we needed is a flexible and extensible scheme for reusing “WebParts sets” and that’s what our extension allows for.

Also since we’re very performance sensitive, and we operate in a multi server scenarios a lot we’ve added web parts blobs caching. Meaning that the site does not have to reach to the database every time a page is rendered.

The very appealing side of the framework is that it can be extended form the bottom (persistence) from the top (editors, controls, webparts), as well as being pluggable with custom plumbing.

The Sidebar Extensions for WebParts Framework

So to put all the requirements together, we needed the sidebars to be:

• customizable (out of the box)
• easy to use for both developers and editors (out of the box) Wow Steve, I can’t really appreciate enough how cool it is to code for it and how nice it is for the users!
• localizable
• reusable
• inheritable for site branches

WebParts path patterns

The main idea was to free the path names from the restriction they had – being hardcoded for a page. So to do it without hard-coding them I’ve introduced path patterns.

What is a pattern?

Basically a pattern is a way the framework is supposed to encode the WebParts  id for the system to identify. Your site can have any number of “named patterns” and the framework gives you means of switching between them. Pattern allow for almost any string to be a part of it although some tokens have special meaning:

Some sample patterns

The problem that can make a grown up man cry…

You’re editing your EPiServer 4 project and suddenly the edit mode stops working. the server reports compilation errors. something along the lines:

Compiler error: CS0433: Type „EPiServer.Global” exists in „c:\WINDOWS\assembly\GAC_MSIL\EPiServer\5.1.422.122__8fe83dea738b45b7\EPiServer.dll” and „c:\WINDOWS\assembly\GAC\EPiServer\4.61.5.83__8fe83dea738b45b7\EPiServer.dll”

The solution is to go to your web.config and edit the compilation section. The section will most probably look something like this:

<configuration>
  <system.web>
    <compilation defaultLanguage="c#" debug="true">
      <assemblies>
        <add assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
        <add assembly="System.Design, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
        <add assembly="System.Web.Extensions.Design, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
        <add assembly="EPiServer, Version=5.1.422.122, Culture=neutral, PublicKeyToken=8FE83DEA738B45B7"/>
        <add assembly="Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
        <add assembly="EPiServer.BaseLibrary, Version=5.1.422.122, Culture=neutral, PublicKeyToken=8FE83DEA738B45B7"/>
        <add assembly="System.Configuration.Install, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
        <add assembly="EPiServer.Configuration, Version=5.1.422.122, Culture=neutral, PublicKeyToken=8FE83DEA738B45B7"/>
        <add assembly="EPiServer.Implementation, Version=5.1.422.122, Culture=neutral, PublicKeyToken=8FE83DEA738B45B7"/>
        <add assembly="EPiServer.XForms, Version=5.1.422.122, Culture=neutral, PublicKeyToken=8FE83DEA738B45B7"/>
        <add assembly="EPiServer.Events, Version=5.1.422.122, Culture=neutral, PublicKeyToken=8FE83DEA738B45B7"/>
        <add assembly="EPiServer.Lucene, Version=5.1.422.122, Culture=neutral, PublicKeyToken=8FE83DEA738B45B7"/>
        <add assembly="ElektroPost.Licensing, Version=5.1.422.122, Culture=neutral, PublicKeyToken=8FE83DEA738B45B7"/>
        <add assembly="System.Data.OracleClient, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
        <add assembly="EPiServer.Wsrp, Version=5.1.422.122, Culture=neutral, PublicKeyToken=8FE83DEA738B45B7"/>
        <add assembly="EPiServer.WebParts, Version=5.1.422.122, Culture=neutral, PublicKeyToken=8FE83DEA738B45B7"/>
        <add assembly="EPiServer.UI, Version=5.1.422.122, Culture=neutral, PublicKeyToken=8FE83DEA738B45B7"/>
        <add assembly="EPiServer.Web.WebControls, Version=5.1.422.122, Culture=neutral, PublicKeyToken=8FE83DEA738B45B7"/>
      </assemblies>
    </compilation>
  </system.web>                  
</configuration>    

in my case only the 4th line referencing the EPiServer.dll was interfering with the editing working, but this can easily be trimmed to only first 3 options, so once you’re done with removing CMS5 entries it could look something like:

<configuration>
  <system.web>
    <compilation defaultLanguage="c#" debug="true">
      <assemblies>
        <add assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
        <add assembly="System.Design, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
        <add assembly="System.Web.Extensions.Design, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
      </assemblies>
    </compilation>
  </system.web>                  
</configuration>    

The root of the problem supposedly lies in EPiServer SDK integrated with Visual Studio and it’s Visual Studio that puts those lines there once you attempt to add a new element with one of its toolbars or use the Insert->New item… from File menu or context menu in Project Explorer.

Thanks to the guys on #epicode IRC channel for helping out quickly with the problem.