|
|
-
A new developer community site
NetFxFactory.org is a new developer community site that focuses on the new technologies included in the Microsoft .NET Framework 3.0 (the technologies formerly known as WinFx).
The objective of this community is to become a reference portal regarding the .Net 3.0 technologies by publishing each month a handle of articles. The articles published will deal with, among other themes, introduction to Desktop Windows Manager programming, identity federation, business services catalog…
Two languages are supported by this community French and English. The members can specify their preferences.
Who is targetted by this community site?
Even if this community targets anyone who is interested in .Net 3.0 technologies, most of the audience is composed of .Net technicians. The two main profiles targetted are developpers and architects. As opposed to the articles targetting developpers, the articles targetting architect do not requires a deep knowledge of the .Net platform as most of these articles presents technogically agnostic concepts. Only the proposed implementation of the concept is presented in .Net.
Anybody can be a contributor
You can become a contributor simply by submitting a first article to webmaster@netfxfactory.org
|
-
The version 1.1 of ProxyFactory has been released. This version supports fully three communication technologies offered by .NET Framework : Remoting, Asmx, WSE 3.0.
These technologies will be soon described as "Old school" though many developments still use them. One of advantages of the ProxyFactory project is to prepare you to the future adoption of WCF by offering a similar development experience. ProxyFactory<ICalculator> __proxyFactory = new ProxyFactory<ICalculator>();
ICalculator __proxyCalculator = __proxyFactory.CreateProxy();
double __result = __proxyCalculator.add(1,2);
The deliverables are available on CodePlex. They include binaires and a getting started package. A new video would be published to demonstrate the WSE 3.0 support.
|
-
Even if the revolution announced by MS with its .Net 3.0 platform is just around the corner, the fact is that its adoption curve will be slow enterprise wide because the revolution goes as far as the OS both on client and server.
The emergence of the WCF platform announces the unification of all communications technologies provided by the .NET platform in a common foundation. However, it is still a safe bet to develop a library to leverage NET 2.0 generics and SchemaImporterExtension mechanisms to offer a similar developer experience.
Such a library already exists and targets only web services communication, it was developed by Christian Weyer from thinktecture but, as opposed to the WCF ChannelFactory<TChannel>, his library doesn’t provide an effective mechanism to handle specific types during the proxy generation process. This is what is tackled by the ProxyFactory by taking advantage of SchemaImporterExtension mechanisms. Futhermore, alternative communication technologies are targeted such as Remoting and WSE. This library offers a convenient way to provide an easy-to-use programming model that first, addresses in a common way two heterogeneous communication channels (Asmx and Remoting) but also help to drive existing applications towards the unification of the communication platforms proposed by Microsoft .Net 3.0 with WCF.
Even if ProxyFactory is based a business contract it doesn’t break any functionalities available to asmx. The well-known asynchronous support still works; therefore using interface inheritance it is trivial, client side, to add the methods allowing asynchronous calls to the original contract.
Thanks to a custom Dependency Property-like mechanism the same level of parameterization of each CommunicationPlatform is still available. It is important to keep in mind that the ProxyFactory federates where WCF unifies; therefore each CommunicationPlatform has its own set of parameters. These are exposed via a Dependency Properties mechanism inspired by .Net 3.0’s. Furthermore, this mechanism is used to define the cache policy associated to the dynamically generated assembly.
This project is available on Codeplex at the following url: http://www.codeplex.com/ProxyFactory so watch out for the first release!
Along with the binaries, a getting started package will be available where you will find details about the concept behind the ProxyFactory and 4 samples to walk through step by step. The first one covers a web service dynamic proxy generation, the second covers a .Net Remoting dynamic proxy generation, the third and fourth shows you additional concepts such as asynchronous calls and proxy configuration using a mechanism similar to dependency properties as described above.
Finally, if you really can’t wait for the release to go public (which will happen sometime between today and tomorrow) check out this video for a quick overview of ProxyFactory.
So gentlemen, start your favorite browser!
|
-
Introduction
The march showers keep one's promises, articles about Windows Workflow Foundation are pouring:
March has even its own CTP announced by Paul Andrew on his blog : Windows Workflow Foundation Beta 2.2 Released Today
This march CTPis a thunder clap in the WinFx CTP sky, indeed its characteristics seem to be NOT compatible :
- "The Beta 2.2 version of Windows Workflow Foundation is NOT compatible with Office "12" ..."
- "The Beta 2.2 version of Windows Workflow Foundation is NOT compatible with the Microsoft Pre-Release Software WinFX Runtime Components ..."
Based on this and the fact that the WinFX January CTP main point of interest was that it came out pretty much at the same time as the galette des rois, we all agree that the February CTP deserves a better fate.
All the code implemented in this post is based on this WWF build.
This post deals once more with the wonderful System.Workflow.ComponentModel.ActivityCondition(previously named System.Workflow.ComponentModel.Condition) class but with various options offered to define its own activities (validator, designer...) as well.
My previous post about the condition management in WWF invited Microsoft to support from the designer the configuration of the Condition property of the IfElseBranchActivity class by a custom condition.
We benefitted from the migration of the code of my previous post to offer this support. As we proposed it on this post in the wwf msdn forum, we have added a System.Drawing.Design.UITypeEditor to offer developpers a "Browse and Select a .NET type" dialog. Before listing in details the steps allowing the creation of an advanced activity, I would again promote the advantages to code these ActivityCondition classes by inheriting from the abstract class : ActivityCondition.
System.Workflow.ComponentModel.ActivityConditionThis base class declares only one method : public abstract bool Evaluate(Activity activity, IServiceProvider provider). Only one but a great one, indeed, this method allows gathering any information on the workflow whether its own properties (thanks to the parameter activity and maybe recursive calls to the Parent property of the Activity class.) or its service (thanks to the parameter provider).
You can define business interfaces to facilitate retrieving specific business properties from the workflow. And, there is no constraints enforced on the service definition, even System.Workflow.Activities.ExternalDataExchangeAttribute (previously named System.Workflow.Activities.DataExchangeServiceAttribute) is not required.
Thus, you can define specific business conditions and package it in specific assemblies. This mechanism replaces advantageously the use of the System.Workflow.Activities.CodeCondition class. Moreover, the ActivityCondition class inherits from the System.Workflow.ComponentModel.DependencyObject class, your conditions can profit from it by publishing their properties through the use of dependency properties.
Unfortunately, as I mentioned previously, these custom conditions are not supported by the designer. But, this post will sweep this weakness.
Define your own custom Activity
It is not possible to act on the System.Workflow.Activities.IfElseActivity and System.Workflow.Activities.IfElseBranchActivity activities offered by WWF in order to support custom ActivityCondition classes. So, we're going to define our own activities.
I recommend to you not to use the Workflow Activity Library project template provided by WWF to develop "system" activities. Indeed, this project template validates the design of your activity. It is annoying when you define a validator for your activity and that your activity doesn't respect it natively as we can see for the IfElseActivity.
Thus I reserve the Workflow Activity Library project template to define business activity (meaning High level activity).
Redevelop the IfElseActivity
As all activities, the IfElseActivity inherits from the System.Workflow.ComponentModel.Activity class through the System.Workflow.ComponentModel.CompositeActivity class. The logic of your activity must be declared in the Execute and Cancel methods of System.Workflow.ComponentModel.Activity. The CompositeActivity provides default mechanisms to support child activities and the IfElseActivity is composed by at least one IfElseBranchActivity.
So, when you want to develop a new activity, in first you must decide from what class will inherit your activity : Activity (a simple activity without children), CompositeActivity (an activity with children) or System.Workflow.Activities.SequenceActivity (The execution of its children is sequential, one at a time.)
We have no reason to change the logic implemented by the IfElseActivity :
- The inheritance from the CompositeActivity.
- The Execute method of the IfElseActivity parses its collection of IfElseBranchActivity activities. For each child activity, the Execute method calls the Evaluate method of the Condition property of the IfElseBranchActivity, if the call returns true, the Execute method calls the ExecuteActivity method of the current execution context on the IfElseBranchActivity.
- The Cancel method of the IfElseActivity parses also its collection of IfElseBranchActivity activities, and calls for each child activity, the CancelActivity method of the current execution context on the IfElseBranchActivity.
Once, the logic of your activity implemented, you can customize its design :
Implement a validation logic for you activity The IfElseActivity is used in conjunction with the IfElseBranchActivity. So, you can define a validator to constrains user input. To define a validator, you only need to inherit from the System.Workflow.ComponentModel.Compiler.ActivityValidator class. If your activity is based on the CompositeActivity, you can use, of course, the System.Workflow.ComponentModel.Compiler.CompositeActivityValidator rather than directly the ActivityValidator but don't forget also to call the base methods in all your overridden methods.
The implementation of a custom validator can be reduced to the implementation of the Validate method. This method must return the errors that occured when the validation process is launched (by the designer for example). The parameter obj is the instance of your custom activity. The definition of an error is guided by the System.Workflow.ComponentModel.Compiler.ValidationError class. The parameter manager allows accessing the validation context and to know if child activities have been validated...
The ValidationError class proposes a specific static method named GetNotSetValidationError to create an error when a required property has not been set.
Guide the design of your activity
A validator offers a canvas that constrains the user input to comply with some pre-defined rules but it doesn't guide the user during the design of the activity. This responsibility is left to the designer as usual in the .NET framework.
WWF provides some ready-to-use designers such as the System.Workflow.ComponentModel.Design.SequenceDesigner class and the System.Workflow.ComponentModel.Design.ParallelActivityDesigner class. Their use is recommended. These designers reduce in a considerable way the creation of designers. WWF provides specialized designers for each activity type (sequence, parallel...). The designer for the IfElseActivity is based on the ParallelActivityDesigner.
This designer provides mechanism to declare if you can insert (CanInsertActivities), move(CanMoveActivities) and remove(CanRemoveActivities) a child activity. You can even act on the menu item named "Add Branch" of the context menu associated to your activity by overriding the OnCreateNewBranch method .
So, our designer will inherit from the ParallelActivityDesigner and the OnCreateNewBranch method will return an instance of our custom IfElseBranchActivity, we allow to insert an IfElseBranchActivity, it will not be possible to remove the last IfElseBranchActivity.
Publish your activity to the toolbox window.
You can define :
- A custom bitmap for the representation of your activity in the toolbox window. To do this, you add the ToolboxBitmap attribute to your activity class.
- And actions that will be executed when the user drags and drops the toolbox item on the designer. To do this, you add the ToolboxItem attribute to your activity class and reference with this attribute the class that contains the actions to execute.
Similarly to the designer, WWF provides a base class specializing the implementation of a ToolboxItem. So, Let's take advantage of it.
When you drag and drop the IfElse toolbox item, the designer proposes to you by default two sub IfElseBranchActivity (for if and else). To do this, you only need to override the CreateComponentsCore method and instantiate our activity by adding two custom IfElseBranch activities.
In the case of IfElseBranchActivity, you don't need to publish it in the toolbox window. You use a specific constructor of the ToolboxItem attribute by passing a boolean parameter set to false.
Redevelop the IfElseBranchActivity
We must act simply on the design customization of the Condition property. As told at the top of this post, we're going to offer a "Browse and Select a .NET type" dialog to choose what condition is associated to the IfElseBranchActivity.
WWF is definitely a great library, because this dialog is already offered with TypeBrowserEditor. However, we cannot simply reference it by using Editor attribute, indeed the ActivityCondition class defines its own type converter.
Moreover, it is nice to filter the types browsed by the TypeBrowserEditor. I prefer to invite you to read this post from Daniel Cazzulino to have more details on this functionnality.
So, the last two steps are : the implementation of a type converter and a type filter.
Implement a type converter
If you want to have more details about type converter implementation, you can read this MSDN page.
The only specificity of our type converter is that the GetProperties method must return the properties of the selected ActivityCondition.These properties can be specific, and the PropertyGrid must be updated accordingly. The internal WWF ConditionTypeConverter solves this problem by using the TypeDescriptor.GetConverter method on the selected ActivityCondition type. Based on the type converter returned, you only need to call its GetProperties implementation.
Implement a type filter
To filter the types browsed by the TypeBrowserEditor, you must implement the ITypeFilterProvider. This interface offers a method CanFilterType and a property FilterDescription. The property is used to name simply the TypeBrowserEditor. And the method as the name indicates it, returns if a type must be taken into account.
Daniel Cazzulino mentions it, but I prefer to draw your attention on it: it's necessary that your filer type provider implements a specific constructor : public xxxTypeFilterProvider(IServiceProvider serviceProvider){}if you want it to be supported by the TypeBrowserEditor.
Conclusion
To conclude, you can download below the source code of a sample application and a video. The sample application is based on a workflow which is composed of two custom IfElseActivity (RioterDeckerIfElseActivity). This sample application is divided into three projects :
- A sequential workflow console application project that contains the workflow,
- A class library project which contains a custom activity condition referenced by the workflow,
- A class library that contains our custom IfElseActivity and IfElseBranchActiviy.
The video shows how to add a custom condition to the sample application.
Have fun!Download the code here.
Download the video here.
Thanks to Thor's help, our collaboration assures more posts around WWF and WCF integration so stay tuned!
|
-
After the various business matters (Napster, Kazaa...) which shook the File sharing generation, an unexpected sponsor contributes to its legitimity (or legality). Microsoft, by offering a new model for defining templates for projects and items in Visual Studio 2005, opens the "zip and share" to your code artefacts.
Share your code templates with friends or colleagues. And we can think that soon we'll find a specific support of these files on IPOD.
But the fantastic "Export template ..." feature is not without weaknesses : the first is the lack of a graphic editor and the second is that no source control support is available. A graphic editor could be so useful, especially when you want to update the item template (adding a wizard...) that is generated by the export template wizard. And you would certainly like to have a better deployment mechanism. For example a checkbox, allowing to open the generated item template in Visual Studio, will be a great solution.
While waiting for possible improvements, and if wizards don't make you stupid, you can sublimate the definition of an item template. Let us note that an item template is simply a zipped set of files containing at least one metadata file (*.vstemplate) and a code file.
Which tools can you use to industrialize the definition of an item template ? What is the best xml editor ? What is the name of this fantastic deployment tool available on the .NET plateform ? We'll use the XML editor provided by default by Visual Studio and MSBuild.
Indeed, a first stage would be to define a project template which would allow the definition of vstemplate file and which would generate item template from the reading of this file. The actions in order to create this promising project template would be the following :
- Define a custom project template.
- Create a specific msbuild target file. This file will be imported by the csproj file of project template defined above.
- Implement specific msbuild tasks making it possible to zip a set of files, to get registry information.
- Insert the calls to these tasks when the famous build target is executed.
- Copy the generated item template to the relevant user's personal data folder.
Creating custom MSBuild tasksWe create at least two tasks : one is to gather registry information and the other is to copy the generated template to the relevant user's personal data folder.
MSBuild offers many tasks by default, unfortunately it is far from being sufficient. But don't panic, Microsoft Research UK has already launched a project which regroups a hundred tasks : .NET SDC Solution Build & Deployment Process & Tools. For what we want to do, we'll spare you the adoption of this project. The definition of an item template is based on the creation of a vstemplate file. We'll suppose that we'll create a simple item template. From a vstemplate file, we can know the path of the image file that serves as the icon for this template and especially the path of the file that is included in this template. The first msbuild task will consist in getting these paths (in order to zip these files to create the item template). The second task will be to get the path of the relevant user's personal data folder.
Get information from the vstemplate file.
To define an item template, it is necessary to zip the vstemplate file and the files that it references.
The path of these files are provided by the vstemplate file. This file is an xml file. Its schema file is available locally at [Program Files]\Microsoft Visual Studio 8\Xml\Schemas\1033\vstemplate.xsd. The installation path of your favorite IDE can be obtained from a data value named "ProductDir" of the registry key named "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS". Of course, the Visual Studio Template Schema Reference is available online on the msdn site, too.
It is therefore very simple to get the requested information (image file path, code file path...) in using the XPathNavigator class.
Download source code. Below, you'll find a rapid preview of the GetVSTemplateInfo msbuild task proposed above.
Get the path of the relevant user's personal data folder.
The item templates are saved in a specic user's personal data folder. You can get its path from the registry key named "HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0". One of data values of this key (UserItemTemplatesLocation) is the desired path.
Download source code.
Below, you'll find again a rapid preview of the msbuild task proposed above. 
Zip the vstemplate file and the files that it references.
It is necessary to zip the vstemplate file and the files that it references to create an item template. Before developping such a msbuild task, I propose you to read, if it's not yet done, my previous post about the zip compression with the .NET framework : Your zip is open.
Don't forget that the two previous build tasks have been provided by the .NET SDC Solution Build & Deployment Process & Tools. And for those who are not to found off gotdotnet user sample, they can join the MSBuild Community Tasks Project. Personally, compared to the tasks listed previously, I prefer the code produced by our english friends.
Copy the item template zip file to the relevant user's personal data folderIn order for your IDE to use your new item template, you must copy it to the folder (the path has been got in a previous task). MSBuild provides a such task : Copy Task.
I chose to merge the GetVSTemplateInfo task, the zip task and the copy task in a same task that I named "DeployItemTemplate". This (bad ?) choice allowed me to produce a msbuild target file more quickly.
Download source code.
Again, below you'll find a preview of the implementation of this msbuild task.
Define a custom project template.
Now, we have all the msbuild tasks required in order to define our project template. This project template will be based on specific msbuild target file that its csproj file will import.
What are the traps to avoid ?
- Trust your msbuild target file.
- Create an file tree structure for the project template.
Creating a msbuild target file.We're going to declare a specific msbuild target which will be executed when the project is built. This target will call the tasks that have been previously presented.
The declaration of this target is done in a specific msbuild target file. If you don't want to face a recurrent warning message when you use your project template, you must trust the custom msbuild target file.
To do this, it's necessary to add a specific string value in the registry key named "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\MSBuild\SafeImports". The value data of this string value must be the path of the msbuild target file, no rule for the value name.
Create an arborescence for the project template.
There must be one and only one vstemplate file by template. So, if you want to add by default to your project template a sample vstemplate file, it cannot be at the same level as the project template.
Download full source code (tasks, file target ...).
Conclusion
Of course, I'm convinced that Microsoft will add quickly a checkbox allowing to open the generated item template in Visual Studio and to modify it and to put it under source control and to wash it ....
If your nights are too long, and the trackmania nations servers don't respond, it is possible to add to our project template a custom item template (with wizards) that create vstemplate file.
I did not want to waste my time to create a specific msi package to install the project template, I definitely lost some time when creating a video demonstrating this project template in action.
Download demonstration video.
|
-
The second version of the .NET Framework holds many
surprises such as ADO.NET, System.Configuration and often the spectacular GZipStream class.
This class represents the gzip data format. This compression format is
specified in RFC 1952.
This class is easy to use. The only trap is the naming rules for the compressed
file. More details about this point are given in a MSDN article named
"NamedGZipStream, Covariance and Contravariance".
But, the action scope of this class is reduced, I admit it. GZip is much less
popular than Zip.
But nothing is lost, it exists, of course, a .NET library released under the
GPL that supports the format zip. But another solution exists, if you
want to give a meaning of your life, if you want to resuscitate a dead
born language. This alternative is the use of the J# run-time
library : vjslib.dll. (It's installed as a prerequisite by Visual Studio).
This assembly provides J# classes to use Zip
compression. We have just found a rationale to J#. Again, if you want to have
more details about this library, I prefer to invite you to read a MSDN article named "Zip
Your Data". I will publish my own C# implementation based on this library
in my next post where it will be still subject to Visual Studio
Extensibility.
|
-
I'm agree with you, Visual Studio 2005 made popular the creation of templates for projects or items.
But I believe understand that you are frustrated, you would like so much to customize the various file properties of the items thus created (Cf. image below).
Me, too. I felt this frustration but the Visual Studio Extensibility forum showed me the way.
The solution consists in implementing a wizard :
- Create a project.
- Add to your project a reference to the Microsoft.VisualStudio.TemplateWizardInterface .NET assembly.
- Add to your project a reference to the EnvDTE .NET assembly.
- Add a new class that implementes the interface Microsoft.VisualStudio.TemplateWizard.IWizard.
- Within the method IWizard.ProjectItemFinishedGenerating, set the file properties of your templated item (projectItem.Properties.Item([propertyName]).Value = [propertyValue])
- Deploy your project. Copy the generated assembly to the "[Program Files]\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" directory.
- Modify the VSTemplate element in the template metadata file to reference your wizard.
More details on the creation of templates are available in the article titled "Visual Studio 2005 - Create Reusable Project And Item Templates For Your Development Team" published in MSDN Magazine.
You can see at these urls the various file properties that can be set :
Of course, we propose you a ready-to-use wizard ItemPropertiesWizard that set specific file properties of an project item. To use it, you must to define a specific custom parameter $itemproperties$ to the VSTemplate element. The value of this custom parameter references the various file properties that you want to set, each file property is bound to a custom parameter as shown below :
 A decker forewarned will have noticed that the proposed wizard looks like Microsoft.VisualStudio.Editors.ResourceEditor.ResxItemWizard used by Visual Studio to set file properties of a resource file (.resx). And so, a such decker will use the property ItemType instead of the property BuildAction to set the build action property of an item. The no-forewarned will have to find the reason for this.
Download source code.
|
-
Would the Grid element be a bad father ? It
is the question that we can ask when we see that the sacrosanct Avalon xml
schema alerts us to the fact the ColumnDefinition child element and the
RowDefinition child element aren't valid children of the Grid element.
However, if you navigate on the url given above, you
see that under the heading named "XAML" Element Usage,
ColumnDefinition element and RowDefinition element are well-recognized as
children of the Grid element. It's why we want to repair this injustice in
publishing a updated Avalon xml schema (We simply
added to the type referenced by the Grid element a reference to the
ColumnDefinition element and the RowDefinition element).
You can also choose to do nothing and wait for a future action from Microsoft.
So, for
resume :
- Do nothing.
- Download the updated Avalon2005.zip file. Extract it. And overwrite the Avalon2005.xsd
file located in the "%ProgramFiles%\Microsoft Visual Studio
8\Xml\Schemas" directory.
Use rather the Grid.ColumnDefinitions element and the Grid.RowDefinitions
element as it is presented below :
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition MinWidth="19" Width="Auto" />
<ColumnDefinition MinWidth="16" Width="Auto" />
<ColumnDefinition Width="*" />
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
<RowDefinition Height="Auto"/>
<RowDefinition Height="*"/>
</Grid.RowDefinitions>
...
</Grid>
|
-
We didn't celebrate
Christmas yet, but I know already that one of letters to Santa Claus arrived at
destination.
Indeed, Microsoft has reactivated one of my suggestions that I sent about the System.Configuration namespace and its support of
generics during the Visual Studio Beta program.
But, unfortunately (or fortunately), patience isn't the first virtue of a
rioter decker. So, we have done works on the support of generics in the
System.Configuration namespace.
Our first effort was to develop a generic collection of ConfigurationElement
class : BaseConfigurationElementCollection<ConfigurationElementType>.
This class accelerates the development of the custom collection of
ConfigurationElement class in providing by default thanks to specified
parameter type several strong-typed methods such as Add, Remove, Clear... and
in overriding several methods such as CreateNewElement, GetElementKey... The
step 2 proposed by wozoi in its post titled ".Net 2.0 System.Configuration store parameters - Part II of
IV" is thus more
guided.
During this implementation, we realized that we weren't the only ones to regret
its no support of generics. Indeed, WCF (aka Indigo) developed its own generic
collection of ConfigurationElement class : ServiceModelConfigurationElementCollection. We tried to merge these works in the class which you can download
above.
Others developments can be done rapidly
(ConfigurationManager.GetSection<ConfigurationSectionType>...). You can
still take part in the development of your favorite IDE.
A complete solution (Class library and sample console application) can be
downloaded below :
Download source code.
|
-
WWF is a fantastic product
for at least two reasons: the first it fills a functional lack in .NET and the
second is that its architecture is based on a fabulous "pattern":
Runtime, IServiceProvider, Host, Executor...
The subject of this blog is the customization of conditions. There are three
possible conditions types available: Code condition, Declarative condition and
Policy condition. If they deliver an actual productivity gain to elaborate
rules and manage them, they don't provide mechanisms to interoperate easily
with a custom or proprietary rule system. In the worst case, you could use the
Code condition to do it with all the supposed disadvantages (The developer will
be constrained to code each time the call to rule system...).
An alternative exists. If you analyze the System.Workflow.ComponentModel.Condition
class, you can see that you can create classes which derive from it. So, we
could develop a custom condition which will establish a gateway to the custom
rule system.
 But unfortunately, when
you want to use it from the workflow designer, it will be impossible for you to
do it. Indeed, the IfElse activity references only two condition types (Code
and declarative). Is there a workaround ?
In fact you can always to set the condition property of an IfElseBranch
activity programmatically. It is enough to open the designer code file of your
workflow and to set the condition property of the IfElseBranch activity
selected.
 But, of course, we must
find another solution. Either Microsoft proposes a IfElseBranch designer that
supports custom condition, or we must develop it. In waiting an action from
Microsoft, I launched out in the development of a custom IfElseBranch activity.
This development was rich in lesson. I propose you to download our work.Download source code (WWF CTP February).
|
-
In a previous post, I
debate on the need of development of a GUI for the BAM management utility. But
another improvement would be very valuable: the implementation of the workflow
for using Business Activity Monitoring presented at this url.
You can leverage SPS technology to drive users through this workflow. The BAM
Portal offered in the new version of BTS could be enriched with these
developments: Collaborative features and BAM management features.
This request has been submitted to Microsoft.
|
-
Even though I'm very
enthusiastic about the efforts made to date around the error handling
management and the new concept of application in the admin console, my feeling
is that the privileged targeted audience of the new version of Biztalk Server
is the IT pros. And what do they love best ? the command prompt, isn't it ? It
seems be an opinion shared with Microsoft. Indeed, the BAM management utility
is a command-line utility.
According to the improvements targeting IT Pros, the BM.exe could have its place
in the new Administration console, another approach could be a wizard GUI
similar as BizTalk Web Services Publishing Wizard or Business Rules Engine
Deployment Wizard.
In waiting for a new
build which would offer a such tool. I have started the development of a
wizard.
You could find at this url: the source code of base classes which exposes a few commands offered
by the BM.exe.
And at this url, you could find a video. This video presents briefely a wizard
application based on the use of the class mentioned above.I will publish the source code of the entire wizard application after
its migration on another wizard framework.
You're a member of the BizTalk Server 2006 Beta Team or a future member
(Sign up here). Think of writing also your letter to Santa Claus.
Download source code.
|
|
|