Showing posts with label VisualStudio. Show all posts

Run .bat and .ps cmd files from Visual Studio 2010 2008

Monday, June 3, 2013

Visual Studio 2010 | 2012

You can use this technique to run windows command files with the .bat and .cmd extensions.

Just as previously, we need to create at least one, and optionally two, external tools.

One that terminates the window after executing.

Here’s the values for you to copy+paste and screenshot.

Field	Value
Title	Run With Cmd
Command	%ComSpec%
Arguments	/C $(ItemPath)
Initial Directory	$(ItemDir)

One that leaves the command window open after executing. Useful if you didn’t put a ‘pause’ in your command file or if you want to leave the cmd window open for additional commands.

Field	Value
Title	Run With Cmd and Remain
Command	%ComSpec%
Arguments	/K $(ItemPath)
Initial Directory	$(ItemDir)

Now we should see our new external tools available on the Tools menu.

However, we’d like to right-click on the file and run the cmd file via Solution Explorer like so:

Customizing this context menu in Visual Studio 2010 is abit different from context menu customization in VS2005/2008.

Click Tools –> Customize… to launch the Customize Dialog.

From that dialog we want to select the ‘Context menu’ radio option and the ‘Project and Solution Context Menus | Item’ from the drop down. I’m going to put the two commands right under ‘Open With…’. You can certainly do whatever you wish. Start this process by clicking ‘Add Command’ button on the same dialog.

So here’s a screenshot with that above paragraph in a picture instead of words:

When we click ‘Add Command’, the Add Command Dialog will open. Select ‘Tools’ from the Catgories list box on the left and find your external command from the command list box on the right. Your command will be named something like ‘External Command {Number}’ where {Number} is the number in your list from your External Tools dialog.

Clear as mud? I’m going to use this to make sure I add External Command 3 and External Command 4 to the context menu.

Now the ‘Project and Solution Context Menus | Item’ context menu should look like this in the Customize Dialog.

Close that dialog and check out your new menu items by right clicking on a file in Solution explorer. You should see your new external commands.

For extra credit, you can go back into the Customize dialog and move your commands around into spot your like and alos create a Group around them.

The finished product looks like this.

Visual Studio 2005 | 2008

his will take you a few minutes to setup but once your done, it will save you countless minutes.

It's not unusual to have scripts in your project or solution that automate tasks. Everything from executing a powershell script, moving files around, or some other custom automation tool you may have written.

The default for double-clicking a cmd file in Visual Studio is for it to open the script for editing.

But what if you want to execute it?

One way is to right click the folder above the file, choose 'Open Folder in Windows Explorer', wait for that window to open, find the file with your eyes again, and double-click to execute it.

I tried using the 'Open With...' menu item and adding cmd but it doesn't allow you to pass in the file.

So what you end up with is an empty cmd prompt window that hasn't executed the script you thought it would.

Ok great so how did you do it?

On the tools menu you can add external tools and add arguments. So Tools -> External Tools and a window will open that allows you to run with cmd and also pass in the initial directory as well as some additional arguments.

I created two:

One that terminates the window after executing

Title	Run With Cmd
Command	C:\Windows\System32\cmd.exe
Arguments	/C $(ItemPath)
Initial directory	$(ItemDir)

One that remains after executing

Title	Run With Cmd and Remain
Command	C:\Windows\System32\cmd.exe
Arguments	/K $(ItemPath)
Initial directory	$(ItemDir)

So now you can select the file in solution explorer, then select Tools -> Run With Cmd.

You could go one step further and add it to the context menu.

There's many ways to get into menu customize mode, one way is to choose View -> Toolbars -> Customize. Make sure to select the 'Context Menus' toolbar and you'll notice a toolbar appear in your menu when you're in customize mode.

This next part is tricky. Leave the customize dialog open - it's semi model, if you close it, you're out of edit mode. Click Tools -> and you'll see you're new command listed something like 'External Command 3', you'll have to remember which ones you created (or yes you could go and customize that text as well).

Hold down control and left click (we want to copy this to the context menu not move it), slide your pointer over the 'Project and Solution Context Menus' menu item in the context menu toolbar, then down to 'Item', and drop it in there wherever you like.

Close the customize dialog.

Now you can right-click on a cmd file in Solution Explorer and select either 'Run With Cmd' or 'Run With Cmd and Remain'.

BizTalk : How To : Rename BizTalk Server Machine Walkthrough

Tuesday, March 19, 2013

Renaming your BizTalk machine

post by Saravana Kumar

Anyone who been working on BizTalk server long enough will know renaming a BizTalk machine is not a trivial task. It always involves quite a bit of manual work, things like

Un-configure the existing setting either using the UI or ConfigFramework /U switch
Deleting the Databases manually,
Re-Configuring it, which will raise tons of errors.

It's never been a smooth procedure. Recently I had to go through this painful process, because due to corporate policy changes, they renamed all of our developer workstations.
Here I'll explain how we utilized the Disaster Recovery scripts available as part of BizTalk installation to help us rename the BizTalk machines smoothly (mainly without the pain of un-configure and re-configure). If everything goes smoothly you should be done in less than 10 minutes.

Disclaimer: Do this at your own risk, it worked for me.
Edit SampleUpdateInfo.xml file:

Navigate to the following folder C:Program FilesMicrosoft BizTalk Server 2006SchemaRestore and open the file SampleUpdateInfo.xml file in your favourite editor.
Find and Replace all the "SourceServer" value with your original Server name
Find and Replace all the "DestinationServer" value with your new Server name.
Stuff related to Analysis, BAM, RuleEngine, HWS, and EDI are commented by default, if you are using them in your environment un-comment the required ones.
Save and Close the file.

Run the scripts to update database and registry:

Run the following command in the command prompt
cscript UpdateDatabase.vbs SampleUpdateInfo.xml

This script will update all the BizTalk databases with the correct server name. You need to run this script only once in a multi BizTalk server environment.
Run the following command in the command prompt

cscript UpdateRegistry.vbs SampleUpdateInfo.xml

This script will update the local registry with the correct server name. You need to run this script on each BizTalk server you have in the group.

Restart WMI Service:
Open the Service control manager (services.msc) and restart the "Windows Management Instrumentation" service. This step is required because most of the administration tasks you perform from the admin console depends on WMI.

Promote the new server as master secret server:
Follow the steps outlined in this link http://msdn.microsoft.com/en-us/library/aa559842.aspx to promote your new server as master secret server.

Configuring the BizTalk Administration Console:
Open the BizTalk administration console, click on the existing node (the one pointing to original server), right-click and remove.
Right click on the "BizTalk Server 2006 Administration" node and select "Connect to Existing Group…". Provide the new Server Name and select the BizTalkMgmtDb database.
Click Ok.

Update your Visual Studio project properties to point to new Server:
Most of your Visual Studio BizTalk projects will be still pointing to the old management db server. Trying to deploy your project will result in an error message like this "Login failed for the user ''. The user is not associated with a trusted SQL Server connection. "

Couple of Caveats:
At this point you should be able to see a working BizTalk Group. I experienced couple of problems,
1. When your try to expand the "Platform SettingsAdapters" and select any adapter from the list, you'll see an error message like this "Unable to load adapter handler for XXXX adapter. (Microsoft.BizTalk.Administration.SnapIn) Access Denied (System.Management)"

The machine name in the error message is pointing to my old server name. I wrote a small console application utilizing the BizTalk WMI classes and they all worked fine. It shows clearly the wrong server name is stored somewhere and the admin console is trying to connect to the old server. BTW there won't be anything in the event viewer to assist you

I opened the SQL Management studio and made the following changes in the BizTalk Management Database (BizTalkMgmtDb)
1. adm_group table, SSOServerName Column: This one had the original server name, I entered the new server name
2. adm_server table, Name column: Again this one had the original server name, I entered the new server name.
Restart all the BizTalk/SSO services.

NOTE: These procedures were performed on a Windows XP workstation (single BizTalk installation), SQL Server installed on the local machine. No named SQL instance. The procedure should work for Windows 2003 on a remote SQL Server with multiple BizTalk servers. I'm not sure about the SQL Named instance setup(example people using SQL Express, where the instance name will be for example ServerNameEXPRESS).

BizTalk - Testing Pipeline Components Approaches

Friday, March 15, 2013

post by: Michael Stephenson

We will begin this post by discussing some of the traditional ways I have seen pipeline components tested, then continue to 2 more recent techniques which I believe to offer significant advantages. To begin with the traditional techniques are:

Traditional Approach 1 - Testing as part of a larger process

In this technique the Pipeline component is developed and then deployed along with a BizTalk solution. Tests are then conducted against the overall process and it is assumed that if the end to end test is successful then the pipeline component has been adequately tested.

The key points about this approach are:

Often problems with the pipeline component are not detected during development because the end to end test does not cover all cases in the component
It is difficult to obtain code coverage information for the pipeline component
It is time consuming as it requires a deployment to BizTalk to be able to test
It is error prone because often you forget to restart host processes and think you havent fixed something that you really have
The component has limited reusability as it is only tested within the context of this process

Traditional Approach 2 - Using abstraction to make the component more testable

In this technique you find the developer has abstracted the logic using the facade pattern which the pipeline component then uses. This means the code in the pipeline component is as simple as possible. The more complex code is in other classes which do not depend on the BizTalk classes and interfaces such as IBaseMessage. This in turn makes these classes easier to test outside BizTalk.

I think this pattern in general isnt a bad thing. but I often see this technique used in conjunction with technique 1. So we end up with a situation where the underlying classes are tested with unit tests and the pipeline component itself is assumed as tested as part of the larger process. The key points of this technique are:

It is better than technique 1 as we are performing some unit tests which validates most of the functionality of the component before BizTalk becomes involved
We still cant test the pipeline component interface without having to deploy to BizTalk
Most of the other points from technique 1 still apply

Traditional Approach 3 - Using Pipeline.exe

I sometimes have seen the technique where a developer will create the pipeline component and then some pipelines. The developer will then use Pipeline.exe to execute the test cases.

The key points of this approach are as follows:

This does not require the artifacts to be deployed to BizTalk
It requires additional BizTalk pipelines to be defined to test the pipeline component
This tool needs to be used from the command line (although you could use the process object to call it from a C# test)
When using this approach you would probably want to validate the output document from the pipeline.exe call to ensure the message is as expected
You cant really interact with the message context before or after the test so this might limit your testing capability or require additional components needing to be added to the pipeline.

The challenge of the traditional approaches

The main challenge which limited the traditional approach to how you would test pipeline components was the ability for the developer to create and setup the IBaseMessage and IPipelineContext objects which you would then use for testing. This resulted in the above 3 approaches being (in my opinion) the most popular way of testing pipeline components.

As result developers were often making their best effort at being able to test pipeline components but always knowing that they could only effectively test so much and there was always a reasonable chance that the component is going to have problems when used.

Newer Approachs

As with previous posts in this series I'm trying to encourage the following desired practices when testing:

We want to make testing the component relatively simple
We want to test the component as much as possible before we start using it in BizTalk
We want the tests to be automated and part of a continuous integration process

In order to implement the approach to testing pipeline components I would recommend either of the following 2 techniques (outlined below) when testing pipeline components. Before I discuss the two techniques some background on the sample (available for download at the bottom of the article):

The sample contains a simple pipeline component which will read the input message using the XPathMutatorStream. When it finds an element matching the desired XPath query the value from this element will be promoted to the File.ReceivedFileName promoted property.

The sample pipeline component is intended to be a fairly straightforward component which can be used to demonstrate how to test a component. The following picture shows the main part of the pipeline component:

In the tests project there are 2 test classes each one demonstrating each technique.

Approach 1 - Testing with the Pipeline Component Test Library

The Pipeline Component Test Library has been around for a little while, but I dont think its used as much as it should be. The library basically provides a simpler API to the PipelineObjects.dll which comes with the Pipeline.exe tool in the SDK.

This means you can interact with the Pipeline.exe type facilities in a simpler way directly from your C# test. You can also access the message and its context much easier than you would be able to by using Pipeline.exe. The following picture shows the code snippet which forms the test of the pipeline component using the pipeline component test library:

In the test you can see you use the Pipeline Library to help tackle the key challenges of the IBaseMessage and the IPipelineContext. In terms of the message you use the libraries helpers to create this message from an input document. For the IPipelineContext this is handled by the library internally because you are creating a pipeline in code to execute the component in.

The advantages of this technique are:

You have full access to the proper IBaseMessage before the test. This lets you remove the dependancy on things like components before yours in a pipeline or adapters because you can do things like set properties yourself.
The technique uses objects that a BizTalk person will be familiar with so the learning curve is not that steep
The tests can be developed very quickly
You control the pipeline so you can add additional components as required

With this technique it allows you to treat the pipeline component like a black box. You put a message in and check the message and context that comes out.

Useful Resources:

Some useful resources on this technique are:

Tomas Restrepo - Creator of the Pipeline Component Test Library

Nick Heppleson - Has an article on how he tests his Message Archive component using this technique

Approach 2 - Testing with Rhino Mocks

In approach 2 i'm going to demonstrate how you can use a mocking framework to help you test the pipeline component. In this example I am using Rhino Mocks. In this technique you are basically defining a dynamic mock for the objects which will be used by the pipeline component. On the mock objects you set expectations for what should happen each time a method is called on the mock object. You then execute the pipeline component and then verify that all of the expectations happened as you planned.

The below code sample shows the equivelent test implemented using Rhino Mocks.

The advantage of this technique is:

It is a very powerful technique which gives you full control over pretty much all of the objects
It is a technique which is common to C# developers
Encourages the developer to think more about the component
Again this does not require the code to be deployed to BizTalk

This technique is much more white box, requiring the developer to have a much more intermate knowledge of what the component is doing when creating the test or as we are all test driven developers this makes you think a little harder about what the component does internally.

Useful resources:

For more info on BizTalk and Rhino Mocks check out the following (click here)

Summary

I think the key differences between the pipeline component test library and Rhino Mock techniques are as follows (i will refer to the pipeline component test library as PCTL):

The PCTL offers a technique which has a shallower learning curve and will be familiar to most BizTalk developers
Rhino mocks offers probably more control over things for very complicated tests
The PCTL is a much quicker way of developing tests, i find that using Rhino Mocks is quite time consuming in working out all of the expectations (especially when you are new to the technique)
It would be easier to refactor PCTL tests when there are changes to your component
In my opinion the PCTL just gives me a little more confidence than Rhino Mocks. This is mainly because the test technique gives me the gut feeling that it is performing like how it will in BizTalk. Where as with Rhino Mocks it sometimes feels that there is a bit of a gap between the mocking and what will happen when it is in BizTalk. I dont really have any hard evidence to back this up but I think the fact that the tests themselves are that bit more complicated to write that they almost need testing in their own right.

So based on this article I would make the following recommendations for your approach to testing pipeline components:

Use the traditional abstraction technique anyway as this is a pattern that can make your component simpler to understand and test
As a default technique use the Pipeline Component Test Library
When you have a special case or unusual component that has advanced testing requirements, compliment the Pipeline Component Test Library tests with ones which use Rhino Mocks to help you do those more advanced things
Use a code coverage tool to ensure you dont miss any tests
Remember to test more than just the core interface such as IComponent as the rest of the code needs testing too!

Biz talk Deployment & Build Automation - Biz Talk 2009 TFS 2008

Tuesday, September 11, 2012

BizTalk Server 2009 comes with support for MSBuild. The question is, how can we use it, and how does it help us? The obvious advantage is of course, that this enables Visual Studio BizTalk projects to be deployed to the production environment without the pain of exporting/importing MSI packages. This is particular troublesome when dealing with large BizTalk implementations, with lots of assemblies, where you need to select and deselect assemblies to be included in the package.

It is possible to automate deployment using BizTalk Server 2006 R*, but not without installing Visual Studio on the production environment. This is because MSBuild can’t build BizTalk 2006 projects, and you need to use DevEnv to do the work. But since BizTalk 2009 projects are C# project, and C# projects is nothing less then MSBuild scripts, BizTalk 2009 projects can be built on environments without the need of Visual Studio.

But there is a catch… –It can build, but there is no support for deployment :(

To manage Deployment, we need to do some customization.

When you create a new Build Type in Team Explorer and execute the build, the default build will execute a set of Build Tasks such as GetSources, Compile, Execute Tests etc. The result of the build will give you a folder with the output of the Build. That is a folder with a bunch of assemblies. To deploy these assemblies, we need to figure out where they should deployed to. The obvious place to find this information would be in the bindings files.

So to make use of the new MSBuild support, we need to create three custom tasks:

Undeploy Bindings - Since we are going to redeploy the solution, we need to remove all previous assemblies and artifacts.
Deploy Assemblies - This Task can optionally be disabled, in case you just want to undeploy. The bindings files will tell us to which BizTalk Application an assembly should get deployed to. if your build results in assemblies that should not get deployed to BizTalk, then these won’t get deployed since they are not included in the bindings files.
Import Bindings - This is the last custom task to be executed, and will create all the port bindings. Similar to the Deploy Assembly task, this one is optional is case you just want to undeploy.

Next we need to include these tasks in our build. We do this by adding a single row to our already created Build Type:

<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />
  <Import Project="$(SolutionRoot)/TeamBuildTypes/Blogical.BizTalk.CustomTasks.targets"/>
  <ProjectExtensions>

The Blogical.BizTalk.CustomTasks.targets file includes all necessary targets, and will execute the Undeploy-, Deploy- and Import Bindings tasks after the Compilation Task has been successfully executed.

That’s it!

There are some architectural constraints and considerations you need to be aware of:

Isolated Solutions

The Visual Studio solution is central in this process, and it’s important that projects within this solution should not be part of, or referenced from within any other solution that is going to be used in any Build Type. The reason for this is that the solution might not be possible to undeploy if it’s referenced by any other assemblies.

Bindingsfile location

In order for the Custom Tasks to find the Bindings files, the Bindings files need to be checked in to a folder named Bindings which needs to be located in the same folder as the Visual Studio solution file. Also the Bindings files need to be named [Some Name].[Target Environment].xml. Where the Target Environment could be something like TEST, STAGE, PRODUCTION etc. Eg Navision.OrderConfirmation.STAGE.xml

Shared Components

Global artifacts, such as generic schemas and pipelines, needs to be handled separately from this Build Process, as these are referenced by any number of assemblies, ports and filters.

BizTalk Applications

This Build Process does not create BizTalk Applications. Nor does it manage its references. Therefore you need to create them manually before deploying. As Applications are normally not created on a daily basis, this should not be a big issue.

Utilizing undocumented BizTalk assemblies

The Custom Tasks does not use BtsTask.exe, as it’s difficult to handle exceptions using for example Process.Start. Instead it uses Microsoft.BizTalk.ApplicationDeployment.Engine (also used by BTSTask, ExplorerOM and Visual Studio). This is working very well, but this is not a documented library. I would really like to see Microsoft ship BizTalk with a better supported Deployment API similar to ExplorerOM.

Installation

The Zip file includes the Custom Tasks library and the CustomTask.target file.

Save the Blogical.Shared.Tools.BizTalkBuildTasks.dll file to preferred directory on each server running the Build Agent. You can use a network share.
Edit the Blogical.BizTalk.CustomTasks.targets file (line 44). Set the <Blogical_CustomTasks> to the directory where you saved the Blogical.Shared.Tools.BizTalkBuildTasks.dll.
Check in the Blogical.BizTalk.CustomTasks.targets file to the TeamBuildTypes folder in you TFS project.

Downloads

Advanced Users Biztalk WIKI : Useful How to Links Part - 5

Tuesday, June 12, 2012

Useful How to Links Part - 5

Bre Static Support Key

http://blogs.msdn.com/b/asgisv/archive/2010/04/29/troubleshooting-bre-policies-failing-to-return-results.aspx

http://blogs.msdn.com/b/richardbpi/archive/2005/11/14/492489.aspx

http://technet.microsoft.com/en-us/library/aa950269(BTS.10).aspx

Calling Data Access from Ado.Net

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

http://www.codeproject.com/Articles/15403/Calling-Stored-procedures-in-ADO-NET

http://msdn.microsoft.com/en-us/library/59x02y99.aspx

Sso Configuration Storing Values

http://biztalk-dev.blogspot.com/2008/03/using-sso-database-for-storing.html

Xml Document XPath Sample

http://www.codeproject.com/Articles/9494/Manipulate-XML-data-with-XPath-and-XmlDocument-C

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

ESB Dynamic Routing using Itineraries

http://abhijitmahato.wordpress.com/2010/09/10/biztalk-esb-toolkit-2-0-samples-content-based-routing/

http://tenalinaga.wordpress.com/2010/11/12/esb-dynamic-resoultion-with-bre-and-uddi-and-itineraries/

http://www.go4answers.com/Example/dynamic-itinerary-orchestration-48755.aspx

http://talentedmonkeys.wordpress.com/2010/04/24/resolving-a-dynamic-send-port-in-a-biztalk-orchestration-using-esb-toolkit-2-0/

http://blogdoc.biztalk247.com/article.aspx?page=7f047745-aa05-4090-bab1-d8742ab23a58

http://allcomputers.us/windows_server/biztalk-2010-recipes---administration-and-operations---debugging-orchestrations.aspx

http://blogs.msdn.com/b/appfabriccat/archive/2010/06/23/4-different-ways-to-process-an-xlangmessage-within-an-helper-component-invoked-by-an-orchestration.aspx

Advanced Users Biztalk WIKI : Useful How to Links Part - 4

Friday, June 8, 2012

Useful How to Links Part - 4

Iterate ArrayList in BRE Business Rules

http://msdn.microsoft.com/en-us/library/aa577384(v=BTS.20).aspx

Programming with Business Rules Framework

http://msdn.microsoft.com/en-us/library/aa561833(v=bts.20).aspx

How to Script Import/Export and Deployment of Business Policies using FileRuleStore

http://msdn.microsoft.com/en-us/library/aa559518(v=bts.20).aspx

SSO Configuration Store Application

http://seroter.wordpress.com/2007/09/21/biztalk-sso-configuration-data-storage-tool/

http://www.novaenterprisesystems.com/Blog/post/Configuration-Best-Practices.aspx

http://blogs.msdn.com/b/vishalag/archive/2008/06/22/biztalk-configuration-store.aspx

http://social.msdn.microsoft.com/Forums/eu/biztalkgeneral/thread/7af04214-0f8e-40a7-ba3b-062be80598ad

http://whiteboardworks.com/2010/03/unit-testing-biztalk-business-rule-engine

Tool Source Code:

http://seroter.wordpress.com/2008/02/28/sso-config-data-store-tool-biztalkwcf-scenario-source-code-available/

Here are a few TechNet Wiki articles that have become available recently. I have usually found it difficult to find relevant content on the TechNet Wiki so I thought it would be good to highlight a few of these.

Improving performance when executing a BRE rule:

http://social.technet.microsoft.com/wiki/contents/articles/high-cpu-when-executing-a-business-rules-engine-bre-policy.aspx

Implement ordered messaging with BizTalk and SSIS:

http://social.technet.microsoft.com/wiki/contents/articles/implementing-end-to-end-ordered-delivery-using-microsoft-biztalk-server-and-sql-server-service-broker.aspx

BizTalk load testing in VS 2010:

http://social.technet.microsoft.com/wiki/contents/articles/load-testing-biztalk-server-solutions-with-visual-studio-2010.aspx

Load testing for simultaneous BizTalk unit tests:

http://social.technet.microsoft.com/wiki/contents/articles/create-a-load-test-to-perform-multiple-unit-tests-simultaneously.aspx

Install and configure BAM in a multi-server environment: http://social.technet.microsoft.com/wiki/contents/articles/install-and-configure-bam-business-activity-monitoring-in-a-multi-computer-environment.aspx