Posts filed under 'C#'
When working with several source control branches, especially with a large solution with many projects, it is not always practical to open Visual Studio to perform a quick build. Using NAnt is one alternative solution, but this requires creating and maintaining a build script. Using MSBuild from the command line is another option, but this involves getting the command line arguments correct, and working with command line output is not easy to visually filter. The same goes for using Visual Studio from the command line.
Gaston Milano has created a simple tool called Build Console capable of loading both MSBuild and Visual Studio solution files, and building any of the available build targets.
It’s main features are:
- The ability to choose which target/project to build.
- A build report in a tree structure to show the status of each project built.
- The ability to choose the verbosity of the build output.
- A coloured build output log to distinguish different types out log output.
- A ‘quick history’ to load recently built solutions.
Whilst a little rough around the edges, it comes in very handy for those times where you just need to compile quickly without the overhead of loading Visual Studio.
Permalink
October 18th, 2007
Adrian Banks
2214 Views
SQL Server 2005 introduced a new feature called the output clause. This enables INSERT, UPDATE and DELETE queries to be run, with the original information which has been changed being returned. This is particularly useful if you want to run a query and know what has been changed by it by returning the identites of the modified rows.
The full documentation for the output clause can be found in SQL Server 2005 Books Online.
In trying to use this feature, I could get it to work in a query window, but when trying it using C# and ADO, it was not obvious how to execute the query and return the results because the ExecuteNonQuery() method of SqlCommand only returns the count of the number of rows that have been updated. After a bit of unsuccessful searching, I came across a post by Keyvan Nayyeri with something that gave me an idea:
OUTPUT clause works like a SELECT statement but its usage differs in INSERT, UPDATE and DELETE commands
Switching my code around to run the update query using the ExecuteReader() method of SqlCommand as would be used for a SELECT query proved to be fruitful, enabling the returned result set to be read.
Permalink
May 1st, 2007
Adrian Banks
3491 Views
If you are using the AssemblyFileVersion attribute to mark your compiled assemblies with specific Win32 file version numbers, you may get a compiler warning with certain revision numbers. The compiler warning looks like this:
warning CS1607: Assembly generation -- The version '2.0.0.070105' specified for the 'file version' is not in the normal 'major.minor.build.revision' format.
This warning is documented as occurring when the version string is not in the major.minor.build.revision format, but does not explain why it happens for the example above.
Frans Bouma updated his existing post with the reason why. The revision part of the version number must not exceed 65535 (ie. a 16-bit number). If it does, the compiler generates the warning. The MSBuild Team posted about the same thing, but also provided the fact that it is the underlying operating system that imposes this limit.
Permalink
April 23rd, 2007
Adrian Banks
3125 Views
Using the latest version (1.35) of FxCop, it is possible to exclude generated warning messages in the source code instead of having to exclude them in the FxCop project file. This is accomplished using the System.Diagnostics.CodeAnalysis.SuppressMessageAttribute class.
To exclude a message, simply mark up the method with the SuppressMessage attribute, declaring both the rule category and the specific rule to exclude:
[SuppressMessage("Microsoft.Design", "CA1062:ValidateArgumentsOfPublicMethods")]
public string ConvertToString(object obj)
{
return obj.ToString();
}
The above example will exclude the "Validate Arguments Of Public Methods" rule from the Design category for the ConvertToString method (although in this contrived example it is probably a bad idea to do so as passing in a null will clearly cause problems).
One extra "tweak" that can be utilised in this scenario is the Justification property. Altering the above code to:
[SuppressMessage("Microsoft.Design", "CA1062:ValidateArgumentsOfPublicMethods", Justification="I do have a valid reason, honest!")]
public string ConvertToString(object obj)
{
return obj.ToString();
}
will allow the person excluding a message to provide a reason for doing so in the code, alongside the exclusion. FxCop (v1.35) currently doesn't display this in its output, but will do in the next release (source). It does however output the justification to a generated report if the options are set to output exclusions to the report.
Excluding FxCop messages in the source code has advantages over excluding them in the FxCop project as it demonstrates that the message has been specifically excluded for that particular case, but also will withstand class and namespace changes. It also makes switching from the standalone FxCop to Visual Studio's code analysis an easier process.
In order to allow the SuppressAttribute to work, a CODE_ANALYSIS conditional compilation symbol must be defined for the project. Without this, FxCop will ignore the suppressed attribute and will still generate a warning.
More details can be found on the FxCop blog.
Permalink
August 23rd, 2006
Adrian Banks
8126 Views
Previous Posts
Feeds