General

Excellent IIS Metabase Helper

7/11/2007

Excellent IIS Metabase Helper Found this : http://agramont.net/blogs/provware/default.aspx http://agramont.net/blogs/provware/archive/2006/07/31/Provware_3A00_-Getting-Started-_2800_Build-001_2900_.aspx Has the potential to be an excellent Metabase wrapper.

Why we use C# for .NET development

15/9/2006

Why we use C# for .NET development In the company where we work, we have a policy of using Java for all major developments. The core reason behind this being that we have a long term aspiration to being vendor and platform independent. Regards the .NET framework the policy is to use VB rather than C#. Having spent some time using both langauges I disagree with this decision. I am not one to ignore company policy but I will try to change it where I think it is incorrect. So, I spent a little time putting a SOAP (summary on a page) together to present to our chief architect. I expect there are many companies out there with a similar policy, so I thought I would post this so you could share my reasonings and perhaps change your own company policies. I wouldn't be appropriate to post the original but here is a public version: SOAP - .NET Language Preference Summary Java is the preferred development platform within our company, but where close coupling with Microsoft technologies is required, development using the Microsoft .NET Framework may be required or preferred. In an aim to reduce the number of languages supported by our company, a decision has been made to select a preferred language for the .NET platform. Our company has selected VB .NET as the preferred language for .NET development. The reasoning behind this is that we already have live applications written using VB .NET (although there are also live C# applications within our company). The status of C# is that it may be used where an application is already developed using this language, but not for new projects. This SOAP proposes switching the status of the VB. NET and C# languages so that C# is the preferred language and existing applications in VB .NET may still be maintained. Operational Perspective The reasoning behind this proposal is as follows: * VB .NET is significantly different to Java in terms of syntax and structure. C# is based on the Java/C++ syntax. VB .NET developers will have a steeper learning curve when adopting Java than C# developers. For this reason C# lends itself better to being a secondary language in a Java based organisation. * The .NET CLR (Common Language Infrastructure) has been submitted to ECMA and accepted. C# has the same status, http://msdn.microsoft.com/netframework/ecma/ . VB .NET has not. C# is better protected than VB .NET to changes in strategic direction. * Both VB .NET and C# have been used within our company to develop live applications. * Typically developers migrated from VB6 to VB .NET as this reduced the learning curve. However the .NET environment is significantly different from VB6, even though it looks superficially similar. The migration from VB6 to VB .NET can result in poorly designed VB6 style solutions running in the .NET framework. * Visual Studio 2005 comes with JLCA (Java Language Conversion Assistant) allowing Java code to be ported to C#, http://msdn.microsoft.com/vstudio/downloads/tools/jlca/ . There is no comparable tool for VB .NET. * C# provides the ability to work with C/C++ style pointers. This is rarely required and should be avoided. The exception to this rule is some forms of interoperability with legacy Microsoft code. VB .NET does not have this capability. * C# supports Java style code documentation – where definitions of properties and methods are commented in such a way as to make the component interfaces self documenting. VB .NET does not support this. * Visual Studio .NET itself was written using C#. Community support for C# is wider than for VB both inside and outside Microsoft, http://blogs.msdn.com/categories , http://www.technorati.com/search/vb c.f. http://www.technorati.com/search/c# . Industry wide there is more demand for C# as shown by the following link: http://www.indeed.com/jobtrends?q=C%23%2C+VB.NET . Financial Perspective * In terms of the cost of multi-skilled developers, the "C# & Java" skillset should be cheaper than "VB & Java" due to the languages similarities. Not only does this relate to less training but also a higher quality of code/output as the developer is more likely to be highly competent in both languages. * The lack of case sensitivity in VB means that there can be no common coding standards across Java/VB as there could be across Java/C#. This further increases the cost of cross training and maintaining those skills. * The internet is the first stop when a development problem is encountered, and here the significantly larger online C# community reduces time required to resolve problems. * The greater industry-wide take up of C# (compared to VB) means that more developers are available to recruit. * Most C# developers were previously Java or C/C++ developers, and most VB developers come from a VB5/6 background. As a result the average C# developer will have more background in object oriented design (and is more likely to be to be competent in Java also). * I don't believe that there is much wrong per se with VB, it's the peripheral aspects such as developer background, community support, and skills availability that make the difference. * As a result I suggest that C# developers will, on average, be more productive than their VB counterparts, saving our company money and time. Conclusion The differences between VB. NET and C#, as standalone languages, are fairly minimal. C# can do very few things that VB .NET cannot, and VB .NET provides a slightly easier migration path for existing Microsoft VB developers. However, in the context of Java being the primary language in the organisation, C# is a considerably better fit as a preferred .NET language. Combined with C#’s status as a ratified standard this provides a strong argument to switch the statuses of VB .NET and C# within the organisation. .... The argument is under review here still so I would appreciate any constructive commments...

Bug in VS2005? Using Typed DataSets with SQL 2005 and stored procedures

14/9/2006

Bug in VS2005? Using Typed DataSets with SQL 2005 and stored procedures I have been a fan of typed datasets since I started using them in VS2005. Using the feature with SQL Express/stored procedures, Express/SQL Statements, SQL Server/SQL Statements all generate my DAL just fine. However, I have found a couple of problems with them when using them with full SQL Server 2005 and stored procedures. '''Problem 1:''' The first problem is basically that the wizard generates stored procedures in the Schema of the user in the connection string. Regardless of whether SQL user or Windows Authentication are used. You probably wil not have created this schema in the database and so the wizard works fine until the finish step where you see the following message... You might change the default Schema to dbo for the user, the wizard ignores this and performs 'CREATE PROCEDURE [user].[spName]...', very annoying. So, you create a schema in your database with the name of the user (and the user access to it) and this problem is resolved. '''Problem 2:''' The next problem you will see is the message: The reason for this is that the stored procedures are created in the user schema whilst the GetData/Fill/insert/update/delete methods still use the dbo Schema. I couldn't find a way to stop this other than changing the properties of the table adapter manually after configuring. However you may note that GenerateDBDirect methods is still set to true in the table adapter properties and the methods are infact generated. This results in ... '''Problem 3:''' When you run your code you see a run time error "Could not find stored procedure 'dbo.yourProcName' " What I ended up doing was to run a script (http://www.geekzilla.co.uk/View4384ACEC-8C9D-452A-83F6-230FFE43C17B.htm) to move my user.spXXX to dbo.spXXX , not ideal but the Dataset works fine after this. '''All sorted...''' Once you aware of what the wizard is doing - creating in user schema and referring to dbo schema - it becomes quite easy to cope with (if not agree with). For a while its behaviour seemed quite random, especially as I had some existing procs in the dbo schema and so some tables worked fine as they created new procs in the user schema and pointed at existing ones in the dbo schema. My final thought is - I get the impression Typed Datasets wasn't tested with SQL Server and stored procedures. But this won't stop me from using them. I hope this is fixed in a service pack soon.

Getting on the Vista developers merry-go-round

27/7/2006

Getting on the Vista developers merry-go-round Trying to keep up with the various Vista Beta releases? Want to develop but not sure which version will work on your platform? Here's a useful set of links to make sure you get the right version of the runtime, SDK, Orcas VS extensions and WCF libs: || OS || Runtime || SDK || Orcas Extensions || WCF || || Vista 5472.5 || July CTP || http://www.microsoft.com/downloads/details.aspx?familyid=1D7F16B3-D2D5-48F7-9494-6696117EE712&displaylang=en || None yet! || http://www.microsoft.com/downloads/details.aspx?FamilyId=E74FECC8-1278-444E-B775-21F9E8E2A586&displaylang=en || || Vista 5456 || June CTP || http://www.microsoft.com/downloads/details.aspx?FamilyID=d6cd6490-af1a-48c3-aebd-389daf45003c&DisplayLang=en || http://www.microsoft.com/downloads/details.aspx?FamilyID=1a994549-94cb-4f61-903d-a8c8e453eef4&DisplayLang=en || http://www.microsoft.com/downloads/details.aspx?FamilyId=63A80A4B-BD27-4124-A2A5-61786ADB626E&displaylang=en || || Vista 5384.4 || Beta 2 || http://www.microsoft.com/downloads/details.aspx?FamilyId=13F8E273-F5EA-4B7B-B022-97755838DB94&displaylang=en || http://www.microsoft.com/downloads/details.aspx?FamilyId=31F9F15D-00E0-4241-8014-2F12679119AA&displaylang=en || http://www.microsoft.com/downloads/details.aspx?FamilyId=5C080096-F3A0-4CE4-8830-1489D0215877&displaylang=en || || XP / W2K3 || http://www.microsoft.com/downloads/details.aspx?FamilyId=62057A6F-185F-41DB-ABE5-678F6FC388F0&displaylang=en || http://www.microsoft.com/downloads/details.aspx?familyid=1D7F16B3-D2D5-48F7-9494-6696117EE712&displaylang=en || None yet! || http://www.microsoft.com/downloads/details.aspx?FamilyId=E74FECC8-1278-444E-B775-21F9E8E2A586&displaylang=en || || XP / W2K3 || http://www.microsoft.com/downloads/details.aspx?FamilyId=8D09697E-4868-4D8D-A4CF-9B82A2AE542D&displaylang=en || http://www.microsoft.com/downloads/details.aspx?FamilyID=d6cd6490-af1a-48c3-aebd-389daf45003c&DisplayLang=en || http://www.microsoft.com/downloads/details.aspx?FamilyID=1a994549-94cb-4f61-903d-a8c8e453eef4&DisplayLang=en || http://www.microsoft.com/downloads/details.aspx?FamilyId=63A80A4B-BD27-4124-A2A5-61786ADB626E&displaylang=en || || XP / W2K3 || http://www.microsoft.com/downloads/details.aspx?FamilyId=4A96661C-05FD-430C-BB52-2BA86F02F595&displaylang=en || http://www.microsoft.com/downloads/details.aspx?FamilyId=13F8E273-F5EA-4B7B-B022-97755838DB94&displaylang=en || http://www.microsoft.com/downloads/details.aspx?FamilyId=31F9F15D-00E0-4241-8014-2F12679119AA&displaylang=en || http://www.microsoft.com/downloads/details.aspx?FamilyId=5C080096-F3A0-4CE4-8830-1489D0215877&displaylang=en || The Vista versions all install the relevant runtime as part of the os install. #$#

Extending Strongly Typed Datasets

23/7/2006

Extending Strongly Typed Datasets Strongly Typed Datasets are a rather nice addition to VS2005 (they don't lend themselves well to acronyms however) You still need to create a database and tables and realationships but using STDs saves a writing huge amount of code. If this code were generated by hand or by a utility such as CodeSmith then the classes could just be edited to add function as required (though most of the benefits of code generation are lost once the generated code is edited). The STD source is of course auto-generated from the xsd file, a convienient way to view the C# source is to type the STD name and use the context menu to 'Go To Definition', or press F12. This will open a c# source file with a guid name. You can edit this file but it will be overwritten each time the xsd is compiled. You can add new methods and properties to the STD classes by using partial classes. First create a new cs (or vb if you swing that way) file with the filename same as your xsd - for example 'ObjectSTD.cs'. Edit the class definition adding the partial keyword as below. You can add a new method to the ObjectRow class within the ObjectSTD class with the following code... Note that private properties and methods are available and intellisense supports these.

Evaluating Expressions

13/6/2006

Evaluating Expressions You can evaluate sums in the fly using .net DataTables. This is how you do it (C# 2005). This can be pretty damn useful. On a recent project we used tokenised strings which were dynamically replaced with values read from a serialized class. Consider how powerful this can be. e.g. (VB.NET 2003)