Using Development Tools via command line

In order to access many handy .Net tools or BizTalk for that matter, you must navigate to the proper directory first, not an option, or launch Visual Studio .NET 2003 Command Prompt.

A way around this is to add Paths to your system Path Environment variables. To do this, do the following:

1. Right-click My Computer, click Properties
2. Click the Advanced tab, then the Environment Variables button
3. Under System variables select Path, then click Edit
4. Add the following to the end of the Variable value field:
5. ;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\;C:\Program Files\Microsoft BizTalk Server 2004\

Now you can perform the following utilities (and more) from any command prompt: installment, gacutil, ilasm & btsdeploy.

Best Practices

I've been working on a best practices document containing sections for C#, .Net, BizTalk 2004, SQL Server, and IIS. Below is the best practices for each of the following technologies, according to me (Scott White).

Feel free to comment, challenge or add to the respected lists. If change makes sense, I'm more than welcome to make it.

Thanks!

Best Practices: C# & .Net

1. Private and class-level variables should be written using camel casing
2. Public members should be named using Pascal casing
3. Use proper namespacing within all your .Net classes & projects such as: [CompanyName].[BusinessUnit].[ProjectName].[VSNetProjectName]
   Example:
   Microsoft.Office.HelloWorld.Ui
   Microsoft.Office.HelloWorld.Data
4. Create separate projects and namespaces for your UI, Data and Business layers
5. Use DataSet when retrieving results from database and the data needs to be reread, serialized, cached or multiple sets of data need to be related and joined
6. Use DataReader when retrieving results from database and the data needs to be read once and displayed quickly
7. Use XPathDocument when reading XML and needing to extract elements (use XPath, etc) out of the XML document
8. Use XmlDocument when needing to perform two or more of the following: read, write or serialize.
9. Use Command objects to execute SQL code or stored procedures
10. Use EnterpriseLibrary (Application Blocks) in your application where possible, as they are a collection of best practices in working with .Net
11. Use StringBuilder object to construct strings instead of using plus (+) sign to concatenate
12. Use regular ‘for’ loop instead of ‘for each’ loop where possible, as traditional ‘for’ loop is faster and more efficient
13. Avoid using DataAdapter objects
14. Avoid using the DataGrid for inline editing, especially the more complex the process and logic is, as this creates something resembling spaghetti code
15. Add attributes to web service classes and their public exposable members by using [WebService] and [WebMethod]. Properly namespace your web service and document the web service and your web methods this way
16. Add XML Comments to all private and public members
17. Use source code control

Best Practices: BizTalk 2004

1. Although simple mappings can be performed using BizTalk Mapper, use XSLT to perform mappings if they get to long and/or complex
2. Do not use Human Workflow Services (HWS) or even install it, as it is not a good Human Workflow engine and Microsoft is going to deprecate it
3. Fix all SQL Server jobs that are created when you install BizTalk, most of them will not successfully run when BizTalk is initially installed
4. After installation of BizTalk (assuming you installed Enterprise Single-Sign On), make sure you backup and document your master secret
5. Use separate Active Directory Users for each BizTalk service and Groups for BizTalk Hosts. This will keep BizTalk more secure by granted minimum access needed as well as making your BizTalk environment easier to scale out.
6. Create separate BizTalk Hosts for each solution deployed
7. Create separate BizTalk projects and namespaces for Orchestrations, Schemas and Pipelines
8. Following:
9. [CompanyName].[BusinessUnit].[ProjectName].[VSNetProjectName]
   Example:
   Microsoft.Office.HelloWorld.Orchestrations
   Microsoft.Office.HelloWorld.Pipelines
   Microsoft.Office.HelloWorld.Schemas
10. Use Enterprise Library Configuration blocks within your Orchestrations to avoid hard coding information in them
11. To avoid manual deployment with BizTalk, script it (using batch files) or create an MSI package to install it
12. Use late binding for send/receive ports
13. Name your send/receive ports after your solution’s namespace, using Pascal casing
14. Use source code control

Best Practices: SQL Server

1. Casing for SQL Server objects should be similar to that of .Net: Public members (tables, sprocs, views, columns) Pascal cased & Private members camel cased
2. Use Store Procedures everywhere possible
3. Document and model all security access to database objects that need to be granted, then write the script for this
4. Write scripts by hand using a text editor (Query Analyzer, UltraEdit, TextPad, VisualStudio.Net) or an intelligent tool such as Erwin
5. Avoid triggers and give much thought to how you write them if you write them as they can have bad side effects
6. Avoid using cursors within your stored procedures as logical code such as this should normally be performed in your application (middle) tier not your database tier
7. Use source code control

Best Practices: IIS

1. Create entirely separate web sites for each ‘Solution’ or ‘Project’ that is deployed to your web server. Do not put all web sites beneath the ‘Default Web Site’ and ‘wwwroot’
2. Document and then modify the NTFS permissions of your web root directories as needed by your web site
3. Use HTTP Header to host multiple web sites on one server/environment
4. Do not install Front Page extensions on a web server

Overloading Web Service Methods in .Net

A largely misunderstood issue in .Net web services is the capability of overloading web service methods. Overloading web service methods is possible and very easy but it helps to have some understanding of SOAP first.

If you navigate to your web service and click the link "Service Description", or just add ?WSDL onto the end of your web service within your browser, example:

http://localhost/MyWebServices/WebService1.asmx?WSDL

You will see the Web Service Description Layer (WSDL). Inside your WSDL you will see your web service methods represented as operations such as:

<wsdl:operation name="Add">
...
</wsdl:operation>

Now if you go into your Add method inside .Net and add try to overload it, the problem you have is that method names within .Net map to both operations and message elements within your WSDL and you cannot have two message names that are the same, example:

<wsdl:message name="AddSoapIn">
<wsdl:message name="AddSoapIn">

Cannot exist twice. The fix is simple, add a WebMethod attribute to both methods and make sure they have distinct names between them.

[WebMethod(MessageName="Add_TwoNumbers")]
public int Add(int x, int y)
{
return x + y;
}

[WebMethod(MessageName="Add_ThreeNumbers")]
public int Add(int x, int y, int z)
{
return x + y + z;
}

Now your WSDL will have message elements with names:
Add_TwoNumbersSoapIn
Add_TwoNumbersSoapOut
Add_ThreeNumbersSoapIn
Add_ThreeNumbersSoapOut

But your operations (within WSDL) will have the following:
<wsdl:operation name="Add">
<wsdl:operation name="Add">

Thus when you generate your proxy class for your web service (IE: Web Reference, or WSDL.exe) then you can open your proxy class and see how it maps overloaded methods to the operations properly.

While it's not necessary to rewrite the WSDL yourself, understanding how to manipulate the WSDL through attributes within your .Net web service is invaluable.

See Also: WSDL spec from the W3C