Sundar's TechBlog

BinaryRibbon 4.0: Easy layout Scale transformation. plus full Vista and Windows 7 Aero Glass support

Continuing with my other post on the new Layout scaling feature that is in Ribbon 4.0, I also want to show off  some more details of this new feature, viz.:

• The Layout scaling is easy to apply - i.e. you don't have to code / XAML the scale transformation yourself.

The control's Window object i.e. BinaryRibbonWindow class has a new property that accepts a double value for the Scaling factor, and that is all to it.

It will scale the entire window - i.e. the Window titlebar, control buttons area, as well as the Ribbon Panel (where you host all your ribbon bar content), automatically with the value you set using this simple dependency property on the BinaryRibbonWindow control.

• The Scaling transform supports Vista and Windows 7 Aero glass fully - i.e. the scaling logic will also ensure that the Aero Glass that is extended into the Window Title frame fully covers the entire area of the newly scaled up/down Window title bar (a.k.a. Non-client area) with glass.

 

A screen shot of the BinaryRibbon running in Vista (without Aero glass), and the layout's scale transform set at the standard 100%:

 

This is a screen shot of BinaryRibbon in Vista (with Aero Glass), its layout scale transform set to 150%: (You can see that the glass is correctly and fully extended to the 150% scaled area too):

 

This is a screen shot of BinaryRibbon in Vista (without Aero), its layout scale transform set to 150%:

Looks cool? :-)

Just wait a day or two , to get your hands on Release 10 of UIControlSuite .NET :-)

- Sundar

BinaryRibbon 4.0 - more layout "goods": Full support for Right-to-Left FlowDirection

Yes, as promised, the BinaryRibbon 4.0 (part of the upcoming UIControlSuite Release 10) will have full Right-To-Left FlowDirection support :-)

Here is a screen shot of the control running its blue theme (with its customised MS Office like ScrollBar control as well), and the UI's Layout running Right-To-Left FlowDirection.

 

 

Stay tuned.

- Sundar

New ScrollViewer (+ ScrollBar) WPF controls in Release 10

UIControlSuite .NET Release 10 will have a new WPF control that I am introducing: BinaryScrollViewer .NET control.

This control instantly replaces the standard .NET WPF ScrollViewer and ScrollBar (Primitive) controls... and it does not just stop there... it also allows you to completely customise the ScrollBar's all UI aspects, by simply letting you to set the desired colours/brushes for the each element of the ScrollBar UI.

This control saves you from spending time in having to tweak into / re-writing the Visual Tree of the ScrollBar controls and the ScrollViewer's Style.

It is all done for you already, with my professional touch ;-), and all that you will need to do is to simply setup the desired colours for each bit of the ScrollBar (Horizontal and Vertical ones) UI, and "pass it on" to the control by merging your custom resource dictionary containing the chosen colours/brushes into your application's Resources.

No more of those days of having to put up with the out-of-the-box Windows Standard ScrollBar UI colours that are pretty much stuck to the OS's themes and hence have no synchronisation to your Application's colour theme.

BinaryScrollViewer .NET is here, to rescue! :-)

 

Here is a screen shot of some of the colour customised ScrollBar controls "in action":

 

 

Release 10 "RTM" date is not far off! ;-)

Stay tuned!

- Sundar

BinaryRibbon v4.0 - Layout goodies

One of the other features i was talking about in my earlier post that is coming in BinaryRibbon 4.0 (part of the Release 10 of UIControlSuite .NET) is the automatic Ribbon content Resizing (thereby performing the required collapse/expand of groups) when the control is scaled up or down.

With this new capability, you can perform a transformation on the ribbon control to scale it up, for example, to get a larger UI, without having to worry about the control/groups rendering quality.

As you scale up / down the Ribbon, the control adjusts its layout accordingly, and at the the same time, renders the UI with the same crispness/clarity as seen in its standard scale (thanks to Vector drawing! :-))

A screen shot of the Ribbon at 100% scale factor:

 

A screen shot of the Ribbon at 150% scale factor:

You can see that the Ribbon maintains the same crispness rendering quality at a 150% scale factor, and has also automatically performed the layout logic to move items into overflow panels, etc., given the constrained window size available vis-a-vis the requested higher scale factor of 150%:

Isn't that cool! :-)

 

New ScrollViewer control in Release 10

OK, I will soon blog about my new 100% easily skin-able ScrollViewer control that is coming as part of Release 10 :-)

With this new scroll viewer control in your toolbox, you are no more tied to using the standard Windows OS Scrollbars!

Forget about having to re-style / tweak the ScrollViewer control template yourself.

You can now simply use BinaryScrollViewer control, and just set your desired colours / brushes for various UI elements of this custom scroll viewer control using the various ComponentResourceKeys (CRKs) the control exposes, and within minutes you will have scrollbars matching the rest of your application UI ;-)

Stay tuned.

- Sundar

Ribbon WPF v. 4.0 control skinning... easy as pie :-)

Yes, in version 4.0 of BinaryRibbon WPF .NET, skinning the control is an absolute pleasure... trust me! :-)

Have a nice set of colours ready in your mind for "that gorgeous" custom skin that you want to apply on the Ribbon control?

Good news! Those colours in your mind are all that you will need, to skin the Ribbon in just few minutes.

The upcoming version 4.0 exposes a set of very easy and intuitive API that you can use to create and apply your custom skin for the control.

The API expose the ComponentResourceKeys (CRKs) of all the relevant resource objects that are used by the control, to render the Ribbon.

You will simply create a custom resource dictionary, use the exposed API to set the various brushes/resources, and merge the dictionary into your Application object's Resources. That is all to it!

Using this API, I was able to create a custom skin and get the app running, in about less than 5 minutes :-) (Of course, I had in mind those desired skin colours ready when I started to create the custom skin).

I have also updated the documentation to show in detail (in XAML as well as in Procedural code) as to how to go about creating your own skin for Ribbon - simple and straight-forward.

 

New custom skins, out-of-the-box

As announced earlier, Release 4.0 of BinaryRibbon WPF, will come with ready to use new additional skins (on top of the already existing 3 Office skins and 1 Windows 7 skin), that you can use straight out-of-the-box.

These custom skins cover 10 different colour themes.

I wanted to show off some of these new custom built-in skins that are available in version 4.0 / Release 10:

Here you go...

Brown

Yellow

Creamy green

Green

Pale Orange

There are five more colour skins in the control. You can play around with these once I make the Release 10 package available to public.

 

Glass support for the Application menu button

One other new feature you will note (even from the screen-shots above) in the upcoming release is that the the Application menu button now supports more precise "glass" rendering, and also can be skinned by accepting a background colour for its internal glass fill :-)

 

There is more to write on the features of Release 10... stay tuned for my next set of blog posts on the details and screen-shots of:

• The new WPF controls in Ribbon 4.0,
• The newer features in Ribbon 4.0 (you can read those hints from my earlier post)
• The cool animation effect of mouse hovering on non-selected Ribbon tab item headers, and
• The new SlideShow .NET WPF control

 

Just a couple of more days to go for Release 10 going public :-)

Stay tuned.

- Sundar

SlideShow .NET control for WPF in Release 10

Yes :-) You read that correct! A little secret that I had kept away from you all.

I have now completed my new WPF control BinarySlideShow .NET - a SlideShow viewer control that can host complex content (including 2D and 3D controls, Images and any other content that you can imagine).

As is obviously expected, the control is highly designer friendly, and it is also very friendly and intuitive to those who love to do things the procedural way ;-) rather than XAML-ing.

The control boasts loads of State Transition / animation effects, including the very popular SnowDustWipe effect that I had introduced in my VirtualizingWrapPanel control.

You would simply instantiate the control, add slide items to it (setup with your slide show content), and simply Play it :-)

The Play() method comes as a couple of overloads, each one providing fine-grain control over how you would want the control to run the slideshow.

The control provides user controlled, as well as automatic - i.e. DispatcherTimer based automatic slide transitions.

All that, and the new version of Ribbon control  v 4.0 (as indicated in my earlier blog post) will all be available in Release 10, which is just a a couple of days away!

Until then, continue to enjoy the current Release 9.7 :-)

Stay tuned!

- Sundar

Version 4.x/5.x of BinaryRibbon WPF (goods) highlights :-)

I am currently very busy working on the next release of UIControlSuite .NET (Release 10), and specifically on the final bits of version 4.x of the Ribbon control for WPF

Like I had hinted in my earlier blog post, BinaryRibbon WPF is getting loads of goodies in its 4.x version... yummy... yummy... I know :-)

OK enough talk, let me now list the specifics of the new features that are in 4.x version of BinaryRibbon for WPF:

New features in Ribbon 4.0

New Custom Ribbon skins out-of-the-box

Ten new Custom skins that you can simply choose and apply to your app instantly.

New Ribbon custom controls

- Scorllbars
- StatusBar
- Checkbox and Radio Buttons as seen in our TreeListView WPF control
- FontFamily and FontSize comboboxes

Layout/ flow direction goodies

- Right-to-left support
- Ribbon auto-sizing feature will support auto-sizing of the control (resulting in automatic minimisation/maximisation and other UI effects) when performing layout transformation on the control (thanks to Vector based drawing!)

 

New features in Ribbon 5 (i.e. part of the planned Release 11)

New and enhanced Visual Studio 2008 designer support

Apart from the currently existing Visual Studio 2008 and Expression Blend Design time support, the control will offer an enhanced custom design time experience for Visual Studio 2008.
This will enable you to easily set up labels, select image resources from within your project resources, and be able to move around controls within the Ribbon control (say across Ribbon groups, etc.) with simple drag-and-drop operations.

Visual Studio 2010 (CTP) support

Ribbon 5.x will also support Visual Studio 2010 (CTP), along with some enhanced design time experience specific for Visual Studio 2010 IDE, including, supplying a Ribbon WPF Visual Studio 2010 Project Template for you to quickly get started with building your Ribbon application in minutes! :-)

My Release 10 iteration ends just after 1st week of July, so you all can expect a CTP of Ribbon 4.0 in couple of days soon.

Yes, as is usual, I am listening to all my customers (and you can see its effect as above :-))
So if you have any wish list of features in mind, please do ping me, and I will certainly try to box it in releases next to Release 10.

My Release 11 iteration timebox begins sometime 2nd week of July :-)

Stay tuned for screen shots and CTP of Release 10 soon!

- Sundar

Vista and Windows 7 Aero glass support in BinaryRibbon WPF

Yes, a new feature is getting in :-) I have now completed the enhancement of supporting Glass rendering on the non-client area in the Ribbon control :-)

By setting a new DependencyProperty named RenderGlassIfOSSupports, the control will render its non-client area with glass, rather than its default Office 2007 non-client area emulation.

Of course, the feature will work only in Operating Systems that supports Aero Glass – i.e. Vista and Windows 7, and only when the DWM composition is enabled.

Here is a screenshot of BinaryRibbon control running in its glass enabled mode in Windows 7 (RC):

You will see that the control renders the glass background for not only its standard Non-client area, but also for its Quick Access Toolbar (QAT) area.

There are a lot more goodies in the “works” for the next release (4.x of BinaryRibbon WPF) … so stay tuned! :-)

You can download the latest version 3.1.256 of the control to enjoy the glass feature in action!

- Sundar

BinaryRibbon .NET WPF 2.0 with Windows 7 Scenic skin

I have now released build 2.0.400 of BinaryRibbon .NET (WPF) with the well awaited Windows 7 Scenic "look-alike"  Ribbon skin :-)

Here is the screen shot, straight from my web site here: BinaryRibbon WPF .NET

I think i have done a pretty much good job here :-) creating this skin as much close look-alike of what it is in Windows 7 or "Weven" as we like to call it ;-)

Of course, as you can see, in my demo application that uses my Windows 7 Scenic Skin, i have setup the tab item groups using my group rendering UI.

You could also simply separate the groups using a separator control, just like how MS present their Ribbon tab items in their Paint and other applications in Win 7. I think its just a question of taste here... I love the group rendering UI rather than just using separators across groups.

Anyway, there you go... :-)

- Sundar

Windows 7 skin for BinaryRibbon WPF

There is a lot of excitement around the new Scenic Ribbon UI in Windows 7, and after hearing a lot of requests from my customers, I am currently building the Windows 7 Scenic Ribbon skin for my WPF control BinaryRibbon .NET.

The new UI looks cool, the major changes observed vis-a-vis the current theme being:

• Rendering colour of various UI elements is different (including the AppMenuButton)
• The ApplicationMenuButton looks rectangular, and is not a toggle button (as is in other themes in the control) but then a drop-down button, and is located alongside the first tab item header in the Ribbon Bar panel.
• The QAT (Quick access toolbar) does not have that nice fancy curved corners, but then takes a rectangular one.

I have almost completed writing the Windows 7 skin XAML, and will be posting here a screen-shot of how it has come out :-)

The updated version of BinaryRibbon .NET (version 1.5) will also be available soon once the skin is ready!

As is currently in my control, this new skin will be available as a new value from the Skin enumeration that you can choose from, which already contains a couple of UI skins including Office Blue, Black and Silver.

Although Windows 7 is now only an RC, I take it Microsoft won't be making any major change to the Scenic Ribbon UI in the RTM release.

Well, even if they did change it in the RTM, its not a big deal, since we can still keep this skin in the control (we wrote it!! :-)), and it does look good and appealing ;-)

Update 17/06/09

Guys, i have now added my new Windows 7 Scenic Ribbon Skin into BinaryRibbon WPF :-)

Please read the latest update in my blog. All Binarymission customers (and potential customers too ;-)) can now download and enjoy Windows 7 Scenic Ribbon 7 skin in their Ribbon enabled apps :-)

Get your copy of BinaryRibbon WPF Build 2.0.400 now.

- Sundar

New WPF control: TreeListView :-)

Phew... I am now getting ready to publish my new .NET control for WPF, a TreeList view control :-) - a hierarchical tree-list control for WPF.

Features-wise, this control is just like my existing WinForms TreeListView control that I have written for WinForms , but written from scratch for WPF in C# 3.0.

I have no qualms or frustrating moments on writing this one... I can say for sure, it was a pleasure all along :-).

Its come out very well, and proves WPF is a star :-). You can see the features stock in my web site soon.

Now, dare I try to port it to Silverlight? :-) Hmmm... I would not "port it", since the base classes that some of my core WPF TreeListView project classes inherits from are NOT in Silverlight. I will have to write them all by myself!

So, I have added the Silverlight version of the TreeListView control to my current list of on-going projects, and will be coming up with a potential release date for the SL 3 variant soon.

But for now, look out for my BinaryTreeListView .NET control for WPF in a day or two for public availability from my web site :-)

 

New Website for TreeListView controls package: http://www.treelistview.com

I have put together a new web site for my treelistview controls package, so customers can buy the package of these treelist controls for WinForms, WPF and the up-coming Silverlight 3 version in one package conveniently, if they intend to buy only the treelist controls rather than the full-monty UIControlSuite .NET package.

OK, enough chat... now, where is my SCRUM Sprint task pack for tonight... :-)

-Sundar

Silverlight 3. Making me happy? :-)

I am pretty excited to see the current beta of the Silverlight 3 (SL3), but the "goods" it is to ship with, is it making me happy?

Having seen the list of things in the bag so far in SL3 (so far), I am pleased with the kind of work the team has put together to address some of those fundamental issues in SL2, but I am still disappointed to see some core bits missing.

Can I push Redmond to get these in the release too, since these missing ones being pretty core needs please? :-)

I am pushing myself hard with my customers to sell Silverlight as a LOB platform, but Microsoft is not really helping much in my efforts I have to say.

I am struggling to understand why Printing support is not in SL 3 list.
I would really appreciate a Document (XPS/PDF) toolkit so my sale of SL can win hearts and minds of my customers.... and I don't see that in SL 3.

Well, that instantly means a business opportunity for me to produce a 100% client side Silverlight XPS/PDF viewer control :-)

Considering we never know when SL 4 would be around, the status-quo of SL 3 is not really pleasing me.
Let me come to my personal frustration about what I am missing in SL 3 directly.
Having built the Virtualizing WrapPanel for WPF recently, I am designing / writing my next Silverlight control - a "Virtualizing Wrap panel".
To be honest, I expected all of my WPF Virtualizing Wrap panel code to be shared across to build my Silverlight variant, BUT I cannot!
Reason: I am missing IScrollInfo interface and (a very handy) VirtualizingPanel base class. I am currently writing all of that myself - its cool (and i am sure i will be able to pick most of the logic i have writen in my WPF variant of the control), but still I could have done things easily with some bare-bones in SL frameowrk classes from Microsoft on this.

Frankly, I think instead of investing too much time adding new 3D stuff/GPU acceleration, Pixel shading et al., i would have really appreciated MS to have brought-in the core and Line-of-business items like that ones I described as "missing". that would have made my life easy!

Well, if I look at it in the positive side, the missing bits in SL3 are my business opportunities ;-)

All that aside, I am happy to see some new stock items: (my favourite ones) Merged Dictionary, Dynamic styling (+ BasedOn), Element-to-element binding, Binding validation UI, Assembly caching, enabling occasionally connected applications (a.ka. O-O-B mode) in Silverlight 3.

OK, let me get back to finishing my Silverlight Ribbon and Silverlight Virtualizing WrapPanel controls :-)

Stay tuned :-)

- Sundar

Feeling relaxed... my WPF Ribbon .NET control released, Silverlight 2 variant coming soon! :-)

Feeling a bit relaxed having completed writing and releasing my new WPF Ribbon control:-)
I am currently in the final stages of completing my Silverlight 2 version of Office 2007 Ribbon control.

Before you ask me the obvious question: How much of my WPF codebase I was able to share to build the Silverlight 2 version?, let me tell you... its been about 30%.

I was able to share only some of my control classes, including value converters, and markup extensions code, but (obviously) none of my complex animations, styles with triggers, and all of my element to element binding bits across all of my XAML bits.It was truly an frustrating (although I enjoyed it!) and eye-watering experience :-(

Hmmm... That really does not sell Silverlight as a so-called "sub-set" of WPF - does it?
Well to be honest, we know SL is only a "conceptual sub-set" since its been written from scratch, and I can see Microsoft is trying its best to keep the API, tooling support and the Toolset to be similar across these two technologies, but that is as much they can go!! A single source, build for both is only a dream I think! :-)

Typically, I always recommend my customers (in my Consulting projects) to design and build for Silverlight first, and then port it to WPF (or if doing in parallel, then base the design on SL). That way you won't hurt yourself too much on the re-targeting exercise.
Ironically, contrary to what I practice in my consulting projects, in my product development, because of the known limitations of Silverlight 2 capabilities, the missing essential features/building blocks, and the remote hope of seeing the next SL version to address these gaps at the time I started to write the control, I never had any plan at first, to build a Ribbon for Silverlight. The plan was only for WPF to be honest, and hence the decision to build WPF to start with.

Half way into the WPF Ribbon, since my design was pretty flexible enough that I was constantly tempting myself to start off the Silverlight 2 variant of Ribbon :-), the Silverlight 2 variant has come along the way too - pretty nicely I would say :-) Rest assured it will see its day-light soon!

I will announce the Silverlight 2 Ribbon control soon, once I have completed the final parts (to support some of the "optional" MS Ribbon Fluent UI guidelines) and some tools to visually generate Ribbon bar and its contained UI elements (rather than to depend on Expression Blend) :-)

Stay tuned for release date announcements, and more upcoming new products, and of course my rants, frustrations, happy moments, and well.. everything "in between".

- Sundar

WCF Duplex contract / Message broker endpoints, and GetHashCode()

While consulting a variety of WCF projects recently, I have found instances of some service implementations that use GetHashCode() on the callback channel objects, to be used in performing tasks like, maintaining a dictionary list of message notification subscribers, etc.

In typical Duplex channel scenarios this is not a problem at all - why? Because, you would not even need to depend on GetHashCode() on the callback - since you are speaking to that unique "service providing" client in the current callback channel.

So there is no need to work with its hash code, unless you are working with it on a Per session InstanceContextMode, where it will be useful to use the hash code.

But things are not that straight forward in the case when the endpoint contract is that of providing Message broker kind of services, where there are multiple potential clients that can subscribe to its services.

Although it is legitimate for service developers to get tempted and use GetHashCode() on callback channel clients (service providing clients), I have constantly recommended against that practice (particularly in the context of WCF endpoints that provide message broker service) for the simple reason that the hash code that the service gets from the callback channel implementers (i.e. the hash code of the InstanceContext objects that you get from the operation context in a duplex scenario) need not be unique, consequently ending up with either potential exceptions being thrown in your service code (for example by the Dictionary<Key, Value> Add () method), or the service ending up working with incorrect "service providing" callback endpoints (clients), thereby causing grief at run-time.

Specifically in a message broker service scenario, one might be tempted to think that the InstanceContext (i.e the service providing client) is unique, so there is nothing wrong in depending on the GetHashCode() call on it.
But the fact remains that,  the service callback implementations are neither asked to provide a custom overridden implementation of the GetHashCode() via the callback service contract, nor there is any guarantee that the InstanceContext (i.e. the servicing client) will provide one on its own.

So there is hardly any "uniqueness" reliability on the hash code that one gets from the callback service client.

Solutions that I keep recommending to my customers are: 

1. Don't rely on the GetHashCode() on the callback service client, but then let your service generate a unique ID/GUID for each of the callback client at the time of their Subscribe() requests on the service, and use it for the purposes like "look up" on the list for keeping a thread alive for a given callback instance, or unsubscribing it from the message notification list, etc.

2. If callback client is also written by the service developer, then provide an overridden implementation of the GetHashCode() in your callback.

One other thing that would come to mind is that you could also require as part of the callback contract that the implementer will provide a custom hash code.

That said, I would not recommend this option at all, since it brings in an implementation technicality specific detail (a non-business domain requirement/details) into the callback contracts, which is very ugly.
Also there is no guarantee that the callback InstanceContext will indeed provide a custom implementation (what if it returned the base implementation?).

Like i said, the best bet is of course, if callback client development is also in your control, then you are better off to write your own overridden implementation for GetHashCode() in your service callback contract implementation.

Enjoy safe WCF coding! :-)

Visual Studio 2005/2008, "Delay signing" message text fuss.

Many people have asked about this to me, with a hesitation in their minds to delay sign their assemblies, given the message text that sits in the "Signing" tab page in Visual Studio (2005 and 2008) Project settings view.

Hence I thought I will blog my replies on this anyway, just so that it could be useful to all others out there with the same worry in mind.

When you attempt to setup partial signing, you can get confused or worried by the message that you see in the bottom of "delay signing" checkbox in Visual Studio setting page.

This is the message that gets people worried (at least at the first look/instance) and gets them thinking if they should skip delay signing completely.

To be frank, that message you see there, is not worth so much of importance as-is. I know what MS is trying to say there, but they have not used the correct message text to convey what they intended to say :-)

All that MS would want to convey there is that if you did delay signing, then (specifically for VS 2005) the hosting process - i.e. the <App name>.vshost.exe will attempt to block any debugging activity once the delay signing switch set to ON is detected.

This was the case at the time of VS 2005. This has been addressed now.

Also, the message is trying to say one other thing - I.e. since you will be signing only with a  part of the full key pair when delay signing our app, the crypto bytes that gets into the assembly manifest will end up being null/0 bytes - which is expected.
But when the app is run, the CLR (runtime verification process) will detect this fact and then fail to load the assembly, since the encrypted hash will be 0 bytes, it will be taken as a tampered assembly, and hence will fail the .NET security verification process, and will end up throwing a FileLoadException, and consequently won't run the assembly.

Hence the message that you see in the Signing tab in the page saying that if you delay sign it, you won't be able to debug or run the assemblies.

But it is not fully correct on the part of MS to say what it says there, with just those words in there, because it can lead you to be confused.

What actually will happen is, in the context of development builds / tests / debugging, we will (obviously) need to switch off the run-time verification process - i.e. via the sn- Vr / secpol toolset + through our local development build scripts / process, which we will do anyway, if we are building delay signed assemblies, and will be debugging it for development tests, et al.

But what Microsoft overlooked (and continues to do so) is the fact that those who delay sign the assemblies will know to switch off the verification process in their sandbox / development machines in order to be able to debug the apps, and they simply came up with that message text that you see in the Signing page in VS 2005/8 setting page :-)

Although this may sound a trivial issue, it will be good on the part of MS to fix this message text in Visual Studio. This has been around from the time of VS 2005, but it is annoying to see this not addressed even in the VS 2008 release.

MS should either change the text, so as to make the information clear, or the note should be completely removed altogether.

I would personally favour the later option, since the host (vshost.exe) does not anymore detect this setting  and disable debugging facilities (as it used to do in the early VS 2005 times), and also considering the fact that developers / teams who will be delay signing their project do know what they should prepare in order to debug/run their delay signed assemblies.

Anyway, until MS addresses this, rest assured that there is no need to get confused or alerted by that little (partially) incorrect message :-)

You can delay sign your apps, and run them, debug them et al.

Just ensure that your development build process has the scripts setup to switch off the run-time verification process.

That said, it is not advisable to simply switch off the run-time verification on all assemblies, since that can bring in security risks to your development machine.

Instead switch off the verification process only based on your delay signed assemblies's public key part token, with which you can then run a command something like this:

sn -Vr *, <your delay signed assemblies's public token part of the full secure key pair>.