Showing posts with label .NET 3. Show all posts
Showing posts with label .NET 3. Show all posts

Monday, April 07, 2008

Redistributable installation of Microsoft .NET framework 3.0 SP 1


Somehow there are no direct link and installation instructions for the .NET framework 3.0 SP 1 on MS site.
Here is how to get it:
1) Make sure .NET 2.0 SP 1 is installed.
2) Get redistributable install of .NET 3.0 SP 1 from here: http://download.microsoft.com/download/8/F/E/8FEEE89D-9E4F-4BA3-993E-0FFEA8E21E1B/NetFx30SP1_x86.exe
3) You may need to install XPSEPSC before installation of .NET 3.0 SP 1. Get it here: http://download.microsoft.com/download/8/D/4/8D4C4B2F-269B-44E1-80EA-BF59143D7BAC/XPSEPSC-x86-en-US.exe




Wednesday, October 10, 2007

How to create WCF service proxy without publishing mex endpoint #2


Important update to my previous article: if your service is defined inside of a namespace - you must specify the namespace using /serviceName option during the 1st step (WSDL and XSD creation).
Updated step #1 example:
svcutil /serviceName:MyNamespace.MyService MyServiceSvc.exe /reference:SomeReference.dll
If you'll miss specification of the namespace - resulting proxy code would be wrong (including even endpoing binding defintion).

Wednesday, August 15, 2007

In order to add an endpoint to the service MyService, a non-empty contract name must be specified.


Are you getting InvalidOperationException while creating ServiceHost for your service and getting message in style of "In order to add an endpoint to the service 'MyService', a non-empty contract name must be specified."? the probable reason is that you've missed contract definition in one of it's endpoints. Go to the endpoints list in your .config file and check that each endpoint has 'contract="MyContracts.IMyInterface"' tag.

DEV012 Building WPF XAML Browser Applications - few patches



Few patches you may need to use for this lab:
  1. You getting "Error 32 SignTool reported an error SignTool Error: Signtool requires CAPICOM version 2.1.0.1 or higher" - solutions is here.

  2. You getting "Request for the permission of type System.Net.WebPermission" - it could be caused by a range of reasons. In my case - I needed to set Execute permissions to "Scripts only" rather than "Scripts and Executables". If it not helps you - here few more receipts:

Wednesday, August 08, 2007

WCF Performance

JSON Date deserialization fails at client
Some time ago I've developed a Comet infrastructure for the ASP.NET Ajax. As part of its possibilities - it enables to serialize server-side objects and stream them to the handling function at client side. It was working like a breeze, until Ive streamed some object with Date field, say something like that:        
public class TestMessage        
{            
public string _s1 = "s1";            
public int _i1 = 1;            
public DateTime _t1 = DateTime.Now;        
}


Now, an instance of this TestMessage was correctly deserialized into JS object, exclude its DateTime fields, which was appearing in following form:
{...}
_i1: 1
_s1: "s1"
_t1: "/Date(777)/"


If youre affected by similar problem here is the reason:
1) JSON representation for the string was changed from @777@ to \/777\/ in the latest Ajax release (to prevent serialization of strings that looks like date into Date format), where 777 is num of milliseconds since January 1, 1970 UTC.
2) Currently - at the server side DateTime object is serialized as "_t1":"\/Date(777)\/"
3) If you stream it as-is to the client-side JS recognizes single \ as escape character and your date actually became /Date(777)/, which is wrong format for deserialization.

So, if you want to stream your objects correctly you here is small RegEx-based utility Ive did for it:        

private static class ReplaceDateOrchestrationRegularExpression        
{            
private const string _regex =                
"(?\")(?\\\\)(?/Date\\([\\d]+\\))(?\\\\)(?<" + "postfix>/\")";            
private static readonly RegexOptions _options = ((RegexOptions.IgnorePatternWhitespace | RegexOptions.Multiline) | RegexOptions.IgnoreCase);            

public static readonly Regex Expression = new Regex(_regex, _options);            
public const string ReplaceOptions =                
@"${prefix}${firstDateSlash}\${body}${secondDateSlash}\${postfix}";        
}        


private static string ConvertToClientSideJson( string jsonedArgument )        
{            

return ReplaceDateOrchestrationRegularExpression.Expression.Replace(
jsonedArgument,
ReplaceDateOrchestrationRegularExpression.ReplaceOptions);        
}

Monday, July 16, 2007

Benchmarking LINQ vs. DAAB vs. ADO.NET



Abstract: This article presents benchmarking results of performance of SP calls using LINQ, Data-access application block and ADO.NET.

Some time ago I was doing LINQ performance benchmarking, looking for an option of replacing our existing data layer with it. One thing that was especially important for me to check - was performance of executing SP's. The reason is that most of our DAL logic resides in SP's at one hand and that performance-critical parts are implemented as SP's as well (for all the good reasons, like possibility to benefit from queries compilation etc).

Below are performance benchmarking results of execution uspGetManagerEmployees SP from AdventureWorks DB. (Basically it does some sort of JOIN to retrieve records of employees data for the specified Manager ID).
I tested three data-access models - raw ADO.NET vs. DAAB (our current DAL workhorse) vs. LINQ (May 2006 preview version).

As a prerequisite for running this test you'll need AdventureWorks DB and installation of LINQ.
Few side-notes:
  • I've left opening of DB connection out of the context of benchmarked section. Only SP execution is measured.

  • I use ExecuteReader rather than ExecuteDataSet, as it is much more lightweight. For LINQ benchmark I using GetEnumerator().

So here goes the test code:

1. Plain ADO.NET:


public static void SqlSPBench()
{
string connectionString =
"Data Source=localhost;Initial Catalog=AdventureWorks;Integrated Security=True";

using( SqlConnection conn = new SqlConnection( connectionString ) )
{
conn.Open();

Stopwatch watch = new Stopwatch();
watch.Start();

int count = 10000;
for( int i = 0; i < count; i++ )
{
using( SqlCommand cmd = new SqlCommand() )
{
cmd.Connection = conn;
cmd.CommandText = "uspGetManagerEmployees";
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add( new SqlParameter( "ManagerID", 3 ) );

using( SqlDataReader reader = cmd.ExecuteReader( CommandBehavior.Default ) )
{
//while (reader.Read())
//{
// Console.WriteLine(reader[3]);
//}
}
}
}
watch.Stop();
Console.WriteLine(
"Running " + count +
" SP's using SQL ExecuteReader took " + watch.ElapsedMilliseconds + " ms");
Console.ReadLine();
}
}


2. DAAB (Data Access Application Block):


public static void SqlSpDAAB()
{
Database adventureWorksDataBase = DatabaseFactory.CreateDatabase( "AdventureWorks" );

Stopwatch watch = new Stopwatch();
watch.Start();

int count = 10000;
for( int i =0; i<count; i++ )
{
using( DBCommandWrapper sp_uspGetManagerEmployees =
adventureWorksDataBase.GetStoredProcCommandWrapper(
"uspGetManagerEmployees" ) )
{
sp_uspGetManagerEmployees.AddInParameter( "@ManagerID", DbType.Int32, 3 );
using( IDataReader dataReader =
adventureWorksDataBase.ExecuteReader( sp_uspGetManagerEmployees ) )
{
//DataSet results =
// adventureWorksDataBase.ExecuteDataSet( sp_uspGetManagerEmployees );
}
}
}
watch.Stop();
Console.WriteLine(
"Running " + count + " SP's using DAAB took " +
watch.ElapsedMilliseconds + " ms");
Console.ReadLine();
}


3. LINQ (using ORM layer produced by SQLMetal.exe - "c:\Program Files\LINQ Preview\Bin\SqlMetal.exe" /server:. /database:AdventureWorks /pluralize /sprocs /code:AdventureWorks.cs):



public static void LinqSPBench()
{
string connectionString =
"Data Source=localhost;Initial Catalog=AdventureWorks;Integrated Security=True";
AdventureWorks adventureWorks = new AdventureWorks( connectionString );

Stopwatch watch = new Stopwatch();
watch.Start();

int count = 10000;
for( int i =0; i<count; i++ )
{
StoredProcedureResult<UspGetManagerEmployeesResult> result =
adventureWorks.UspGetManagerEmployees( 3 );
IEnumerator<UspGetManagerEmployeesResult> enumerator = result.GetEnumerator();
//while( enumerator.MoveNext() )
//{
// Console.WriteLine( enumerator.Current.LastName );
//}
}
watch.Stop();
Console.WriteLine(
"Running " + count +
" SP's using LINQ took " + watch.ElapsedMilliseconds + " ms");
Console.ReadLine();
}


Here are timing results of this benchmarking test:
  • Running 10000 SP's using SQL ExecuteReader took 42806 ms

  • Running 10000 SP's using DAAB took 46443 ms

  • Running 10000 SP's using LINQ took 55136 ms




Results
So, comparing to the raw ADO.NET - DAAB is 8% slower and LINQ is 28% slower.
Comparing to DAAB - LINQ is 18% slower.
CPU usage intensity is about 2% average for raw ADO.NET vs. about 8% for DAAB vs. about 20% for LINQ - order of magnitude worse than raw ADO.NET (CPU graphs captured with perfmon below).


Fig. 1 ADO.NET - CPU usage


Fig. 2 DAAB - CPU usage



Fig. 3 LINQ - CPU usage

In overall - this performance overhead is quite disappointing. I still consider to use LINQ, as we have DAL/BLL servers in our architecture, which we may merely upgrade to faster hardware, while isolating thin-client computers from this performance overhead. I think it's a big challenge for the LINQ team to address its performance.