.NET Stuff
Everything related to programming with the .NET Framework.
Yesterday's third Alabama Code Camp was a good experience for me. Contrary to my post on 9/12, I did not do a talk on Windows Communication Foundation, but added a session on creating an Extender with ASP.NET AJAX ("Atlas").
The evening before the event, I was asked to take over a session for Joe Healy, who had a family emergency. His talk was an introduction to ASP.NET AJAX and fit right in with mine. I had to scramble to prepare for that talk, but managed to do it just in time for the session's start.
P.S.: To those who attended my sessions, thank you for the feedback
and the response. I enjoyed the questions and interaction. The slides,
code and demo scripts will be posted later today.
Upcoming Code CampsNext spring, there is a Code Camp in the works for Mobile. I will likely make plans to attend and present some sessions there too.
A code camp is scheduled in Atlanta on January 20th. I have not yet made a decision about attending.
The Alabama Code Camp is having its third edition on Saturday, October 28th in Montgomery (Auburn University at Montgomery). I missed the second edition, because Huntsville is quite a while away from Troy. However, Montgomery is probably as close as it will come, so I will be there.
I have submitted a proposal for a talk on unit testing with Visual Studio Team System, and I am considering an updated talk about web services with Windows Communication Foundation (WCF) and a new talk about Windows Workflow Foundation (if I get around to developing some demos for it).
I truly enjoyed the talks I attended at the first Code Camp. The content was interesting, at the right level, and presented well. I encourage every developer in the area to attend. There are already a number of sessions scheduled, but I believe there will be many more to come.
See you in Montgomery!
The title of this post might actually be more appropriate if it was called what aren't they planning. If you've been reading my blog, you'll know that I was an active beta tester during the Visual Studio 2005 beta period. Microsoft sent me (and many others) a Customer Appreciation Award. Nice token, thanks for that.
However, after the release of VS 2005, I still found some annoyances. I posted two feedback items at the Microsoft Connect site ([1] and [2]) on November 21. Only now have I gotten feedback on those items' status. I can understand that, the team had probably lots of other things on their mind, such as VS 2005 Beta 1.
However, I am concerned about the reply that was posted for both topics. If you have a Microsoft Connect account, I encourage you to look at the items and judge for yourself; but, in my opinion, these are fairly minor changes. One would require adding a missing runat="server" attribute to a tag when Local Resources are generated and another would involve automatically generating resource entries for columns in a GridView. The response I got to both items basically stated that these items won't be fixed for the Orcas timeframe because they would produce breaking changes and the goal for Orcas is to have "a high degree of backward compatibility" [3]. It turns out that the requests I submitted are in the "Red" bits (read the blog post at [3]).
I am concerned because first of all, I was hoping for a fix for these items in a Service Pack; and seeing as how "Orcas" is now supposed to be just a Service Pack where it concerns "Red" bits (again, see [3]), I was certainly hoping for a fix in that time frame. Now, it turns out that even such minor feature changes are not considered for Orcas. So, it seems to me that
Orcas = VS 2005 + (WPF, WCF, WWF designers)
just like
.NET 3.0 = .NET 2.0 + WPF + WCF + WWF
When will that huge dev team at Microsoft get going on delivering high quality software on time on a reasonable schedule?
Sven.
P.S.: Those readers who think I believe Microsoft is the next best thing since sliced bread... there you have it ;o)
[1]: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=104600
[2]: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=104598
[3]: http://blogs.msdn.com/somasegar/archive/2006/05/18/601354.aspx
(Note: This is my first "live" blog post...)
I am in Atlanta for Windows Vista Developer Training. I've had a chance to get used to the user experience (UX) in Windows Vista, and I like it. The developer side of Vista is exciting also, but is clearly still in the works. The lab exercises that are provided are those that were also used during the PDC. They have been updated to an extent.
But on my machine, I installed the Vista July CTP build (build 5472) with its matching .NET Framework 3.0. The Windows Communication Foundation lab 2 went fairly well, but did require some changes to the code. I've uploaded my solution for lab 2 here [2]. Hopefully, this can be of use to someone who's trying the lab on a recent build.
The main differences are here: The Session property of the OperationContractAttribute is now called SessionMode and has changed from a boolean value to an enum. The MSMQ exercise in the lab requires an additional configuration attribute in the tag, "exactlyOnly="false"". (Unless you enable transactional support first; but in the lab, this is done later)
[2] http://www.adduxis.com/downloads/WCF_HOL2/TradingService.zip
At a customer's site, an application needed to format and accept formatted input for currencies. They had already made several attempts at getting the .NET 2.0 WinForms MaskedTextBox to behave the way they wanted, without success.
A quick search reveals that they were not the only ones struggling with this issue. However, Irena Kennedy [1] had posted some sample code that would make the MaskedTextBox behave more appropriately. While the sample provides an excellent overview of how to handle currency values, two features were lacking:
- Support for the currency group separator (the , in the US English culture)
- Support for different cultures (important, considering the fact that the default MaskedTextBox allows you to specify a culture)
The download below [2] is a zip file containing a sample implementation for both of the above features. The code is based on Irena's code. Feel free to download this sample and use it in your applications. However, I provide no warranty whatsoever that this CurrencyMaskedTextBox will suit your needs. If you make any modifications, please continue to include my name and Irena's name.
[1]: http://blogs.msdn.com/irenak/archive/2006/03/21/556434.aspx
[2]: http://www.adduxis.com/downloads/CurrencyMaskedTextBox/CurrencyMaskedTextBox01.zip
While converting a project from VS.NET 2003 to Visual Studio 2005, I also converted the unit tests to the Visual Studio Team System unit testing framework. While I believe that the unit testing framework in VS 2005 has merits, I am not sure if I am ready to dump NUnit. NUnit has a major advantage over Visual Studio for the specific project I am working on: it can correctly compare the contents of arrays.
Suppose you have a custom class. In order to properly compare two instances, you override the Equals method. Both NUnit and Visual Studio Team System will use the Equals method in their respective Assert.AreEqual methods.
However, NUnit will compare arrays on an element-by-element basis, calling the Equals method on each element in the array. Visual Studio Team System expects you to iterate over the array and call Assert.AreEqual for each element (which I would think is what NUnit does under the covers (I haven't actually looked at the source code, but it seems to make sense)). If you supply two arrays to Visual Studio's Assert.AreEqual, then the unit test framework will consider the arrays equal if they refer to the same memory address (reference equality).
P.S.: There is one more difference that makes NUnit preferable in certain situations. NUnit introduces a concept of "Categories." Each unit test can be assigned to one or more categories. You can then elect to only run unit tests in a specific category, or exclude unit tests from a specific category. For a large project, or a project where you know under certain circumstances tests will fail, this is particularly attractive.
UPDATE: According to the documentation, the Team Edition for Testers (and therefore Team Suite) provides the notion of Test Lists, which allow logical groups of tests to be created. Sadly, this means developers have to pay extra for this functionality if they choose to use the Team System testing framework.
A customer asked me if it was possible to create a post-build event in Visual Studio 2005 that would only be run if the active mode was "Debug."
A brief search in the Internet (using A9.com, to keep getting "a piece of the Π") revealed that there was no "built-in" support or any solution previously posted. However, the solution is rather simple, almost trivial. Build events are just commands that get passed to the command line interpreter (with some escaping taking place).
I remember that MS-DOS used to support IF statements for batch files. The Windows Server 2003 command interpreter (cmd.exe) still does, and this is the syntax:
IF [NOT] condition command
Type "help if" at the command prompt to see more information. IIRC, the MS-DOS IF statement was not nearly as extensive as the one supported by cmd.exe.
Combine this with the fact that the build events provide several "macros" (variables is what I would call them) that are replaced with values before the command is sent to the command line, and you get this command:
IF /I "$(ConfigurationName)" == "Debug" <command to run>
The /I switch makes the comparison case-insensitive. The quotes around the macro name are necessary in order to make the command interpreter see it as a string. <command to run> can be replaced with the command. If the command contains spaces, it must also be enclosed between quotes.
If you need to execute multiple commands for a single condition, there are two ways to achieve this: either repeat the IF statement on as many separate lines as you have conditional build events, or put them all in a batch file. The latter method would definitely be the preferred method. Note that you cannot put parentheses () around the multiple commands. In a batch file, each command must be and can be separated by a newline character. However, each build event must be separated from the next one by a newline character as well. There is an inherent conflict there.
During my talk at the Alabama Code Camp, I demonstrated how you can host a soap web service in a WinForms application (or a Windows Service, etc.). However, my solution required the use of SOAP over TCP, which does make it less interoperable.
Angel Machin has a post that would allow any .NET application to host HTTP web services (using Web Services Enhancements). I have not tried this myself, but I got the link from William Stacey's blog.
William Stacey himself hasn't been idle either lately. He posted an improved custom solution to create a security context token on Channel 9. His first solution can be found on his blog and as a complete sample in my Alabama Code Camp downloads (Demo 2). I will probably change an implementation of web services I was working on to this SRP implementation. It is standards-based (which makes long-term maintenance, including maintenance by others) easier and promotes better security because the protocol has seen extensive reviews by the security community.
Alabama .NET code community, if you were not already aware, mark your calendars: on October 29th, the first Alabama Code Camp will be held in Birmingham. It's an event for developers by developers, and registration is free (but required). You can find registration information, directions, and session listings at their web site.
I will be speaking about Web Services Enhancements 2.0 and 3.0 and specifically how those products can be used in real-world applications. I am developing a commercial application at this time that uses WSE 2.0 (and soon 3.0), so I will be able to provide some interesting insights.
I will post a link to my presentation and code downloads on my blog shortly after the Code Camp is over.
I hope to see you there!
I apologize that it has been a while since I have posted anything on my blog. I have several ideas in the pipeline, including some management posts, but both professional and personal enterprises have kept me from actually creating any content.
I have been working with July Community Technology Preview of VS 2005. I had already mentioned that many bugs in Beta 2 had been fixed in the June CTP. By using the July CTP more in-depth (including at a customer's site), I have indeed been able to validate that those bugs have been resolved.
I have to say though that the environment works a lot better for C# than it does for VB.NET (at this time). I believe that VB.NET's background compiler still has some issues left. Even though the memory leak is gone, the environment is really slow when a line is being edited where a warning or error occurs. It may take 5-7 seconds before the environment responds again. (This is running VS 2005 July CTP (team suite) in a virtual machine (MS Virtual PC) on Windows XP Professional SP 2 with 512 MB of RAM).
There are several new features in the IDE I like a lot. I believe that for managing projects, the most important improvement is that "solution folders" can now be created which allow the solution's projects to be grouped together logically instead of allowing only alphabetical listings. I've seen that a popular way of grouping projects in a solution goes something like this: "Client", "Server", "Service Interfaces", "Data Access", etc. In other words, grouping the projects by the logical application layer to which their output belongs. This is also my first use for the solution folders. I am wondering if anyone has a more creative use for solution folders?
I wrote before that I would validate fixes for the bugs I found previously in VS 2005. Unfortunately, many had not been fixed in the Beta 2 release. The two most annoying ones are documented in [1] and [2]. They are particularly annoying because they deal with cryptography. As such, any application that relies on one of these cryptography features (a major project I am working on relies on both) won't run properly.
Now, the good news is that in the June 2005 Community Technology Preview, many bugs are fixed, including the PasswordDeriveBytes one. The memory leak in the VB.NET background compiler [3] also seems to be gone. These fixes result in a much more workable environment. I will be trying (again) to port the project to VS 2005. Hopefully for good this time.
[1]: PasswordDeriveBytes returns different results than .NET 1.1
[2]: RSACryptoServiceProvider.SignHash fails with "Keyset does not exist"
[3]: Memory Leak in VS 2005 Beta 2 (possibly related to vb background compiler)
About 2 months ago, I stumbled upon a slightly disconcerting SQL injection attack vector.
Most guidance that deals with avoiding SQL injection attacks includes using ADO.NET Command objects and their Parameters property. When you combine the use of ADO.NET Command/Parameter objects with SQL stored procedures, you should be protected well against SQL injection attacks. (At least, that's what I understand from the guidance available from Microsoft at [1].
Now, this seems to work effectively: bad "characters" are somehow filtered out. I am not sure where this happens, in the Command object or by the stored procedure (I've heard some conflicting statements about that from Microsofties).
However, there is one scenario in which this doesn't work at all, and that's when your stored procedures create a dynamic SQL statement. So, if your stored procedure looks like this:
CREATE PROCEDURE dbo.InjectTest
(
@Input varchar(20)
)
AS
BEGIN
DECLARE @Sql varchar(60);
SET @Sql = 'SELECT * FROM Entries WHERE ID = ''' + @Input + '''';
EXEC (@Sql);
END
GO
And then you call that stored procedure as follows:
Dim Conn As New SqlClient.SqlConnection("server=(local);database=Tests;integrated security=sspi;")Dim Command As New SqlClient.SqlCommand("InjectTest", conn)
Command.CommandType = CommandType.StoredProcedure
Command.Parameters.Add(
New SqlClient.SqlParameter("@Input", SqlDbType.VarChar, 20))Command.Parameters("@Input").Value = "' OR 1 = 1 --"
You'd actually select all rows from the table, or in other words, a SQL injection attack is possible. And while you should always validate user input as early as possible in your application, a string like that might be considered valid in many scenarios.
Note: This is with .NET 1.1 and SQL Server 2000. I have not tested this on other platforms. I am especially eager to find out what would happen in .NET 2.0 and SQL Server 2005, but I have not had a chance yet to install SQL Server 2005.
[1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetch12.asp
I learned a new thing today: static local variables (a feature inherent to VB.NET) and serialization don't mix.
Here's what I did that did not work. I have a class whose objects can expose themselves as objects of a different class. Because I am not familiar with any design pattern to do this (maybe the actor-role pattern (or role pattern for short) will do this?), I came up with this solution:
Public Readonly Property StringAsSentence As Sentence
Get
Static RetVal As New Sentence
' More code here to initialize the sentence
Return Sentence
End Get
End Property
Now, it turns out that the way the VB.NET compiler gets around the Framework's inability to use static local variables is by actually declaring that local variable as a class level Shared (static in C#) variable. Patrick Steele has a good explanation of this process.
The problem seems to be that although the MSDN document states that StaticLocalInitFlag is Serializable, it is not. Therefore, while trying to invoke a remote method that uses an object of the class that defined the above method as a parameter, I get the following error message:
The type Microsoft.VisualBasic.CompilerServices.StaticLocalInitFlag in Assembly Microsoft.VisualBasic, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=<snip> is not marked as serializable.
I couldn't actually find this exception message anywhere on the Internet, so I was a bit at a loss at first. Also, in the documentation for .NET 1.1, the StaticLocalInitFlag class is not documented. (The URL above refers to the documentation for .NET 2.0, but states that it applies to .NET 1.1 also.)
Here's how I tried to solve the problem at first. I tried to change the property into a function, thinking that the Framework wouldn't try to serialize this no longer. Unfortunately, I wasn't paying attention to what I had just read in Patrick Steele's blog, because as long as that local static variable exists, it will turn into a Shared member variable of the class whose objects needs serializing. It continued to fail. So I just removed the Static declaration and the problem was solved.
If you are reading my blog, then by now you have figured out that Visual Studio 2005 Beta 2 has gone live. The download for MSDN Subscribers is free, if you can wait until your connection has pulled in 3.75 GB. Alternatively, you may order a DVD for a minimal cost.
I haven't tried it yet, but I will be sure to validate that all the bugs I posted on "LadyBug" have been resolved. I'll keep everyone updated.
The good news is that Microsoft now allows Beta 2 applications to be used in production environments. You will need to agree to the Go-Live license.
More good news comes from my web host, CrystalTech. I have always been impressed with them, but now they are offering anyone a free ASP.NET 2.0 Beta 2 test platform. You can find the details here. As can be expected, the plan does not contain all the features of their commercial plans, but they do give 30 MB of SQL Server disk space and 30 MB of MySQL disk space for free, and even 5 e-mail accounts. They even offer support!
Not that I generally tend to complain about features I don't use, but I really wonder who suggested the following feature.
Classes (in code view) in the editor (at least for VB.NET) now have an active properties window, i.e. there actually are properties listed for classes. Actually, there are possible attributes listed for classes. To be 100% correct and complete, there are only 3 attributes listed: COM Class, COM Visible and Serializable.
You can set either of these attributes to False or True, which will result in a code change. So if you have this code
Public Class Test
End Class
And you change the COM Visible property to False, this is what you get
<SYSTEM.RUNTIME.INTEROPSERVICES.COMVISIBLE(FALSE)> Public Class Test
End Class
Here's why I have a gripe with this feature
- It requires you to use the mouse to enter code in a code editor window. Bad idea if you ask me.
-
It doesn't care which Imports have already been declared, it always uses the fully qualified class name for the attribute.
So even if you already have typed
Imports System.Runtime.InteropServices
the generator will still insert the entire string as indicated above. Too much clutter for no good reason.
-
It's not customizable. For example, I want a line break after each Attribute, but it doesn't look like it's possible to configure that.
- And perhaps above all, COM Visible is False by default (I have experienced this oddity after converting an assembly designed for COM Interop to .NET 2.0), yet in the Properties window, it is set to True if the attribute is not used to decorate the class, indicating that that's the default value.
- Why only these three attributes? Because they are the most used ones? Bad reasoning, because everyone knows the most used attributes and can type them easily. The ones that would require use of a code generator are the more complicated ones. If you ask me, the attributes for Code Access Security would have been better candidates for inclusion in that list. And anyway, are the COM attributes really used that frequently?
After reading two blog posts ([1], [2]) about Nullable Types and consulting the beta documentation for .NET 2.0, here is what works in VB.NET (and not more than that from what I can gather):
Dim i As System.Nullable(Of Integer)
i = 10 ' Nothing new here | pun intended ;o)
i = Nothing ' OK, so this is new... no more boxing/unboxing required then I guess
If (i.HasValue) Then
Console.WriteLine(i)
Else
Console.WriteLine("Undefined")End If
Dim j As Integer
j = i ' Works only if i actually has a value...
i = j ' Works always. Obviously, because j, being a regular value type, always has a value, even if unassigned.
No ? to indicate a nullable type (or other shorthand), no ?? operator to choose between the value of the nullable type instance or an alternative, etc. Hopefully in a future version.
[1]: Paul Vick's blog entry
[2]: VB.NET Team blog entry
I have been working with the latest "publicly" available (that is, if you have an MSDN subscription) release of Visual Studio 2005.
There are some great new features, both in Visual Studio and in the .NET Framework 2.0. As a Visual Basic.NET developer (mostly), the feature that I like the most is that VB developers finally have access to build events.
I have been filing several bugs in recent days, but still, overall the product is workable. I have converted a major development project from VS 2003 to VS 2005. I did it mostly because I wanted to see how many changes would be necessary. It's manageable, and if you follow good coding practices, it shouldn't be a headache at all. Even ASP.NET projects seem to convert just fine. I was a bit worried about that, because there are significant architectural changes to ASP.NET.
The one thing that bugs me the most about the new VB.NET compiler is the warnings about using unassigned variables.
Take this example:
Dim obj As Object
If (Not obj Is Nothing) Then
obj.DoSomething()
End If
(Sorry, I have yet to figure out how to format code properly).
This will result in a compiler warning (error in C#, by default) because the object has not been assigned a value yet. It seems to me that this warning can be avoided, because that's exactly the scenario I am testing for. Of course, the code above would not make much sense in the first place. A similar scenario is where you check for an object reference in an exception handling routine, as in the case below:
Dim obj As Object
Try
obj = CreateObject()
obj.DoSomething()
Catch ex As Exception
throw ex
Finally
If (Not obj Is Nothing) Then
obj.Dispose()
End If
End Try
This case is valid, because it tests in the Finally clause for an object reference. It could be that the exception was thrown while the object was being initialized (by CreateObject() in this case, could be a constructor too).
The solution is to assign Nothing (null) to the object at declaration or somewhere else before you try to use it. Unfortunately, it seems that this solution can make matters worse. I hope a fix will be found for this before the final release.
BTW: This is bug #FDBK22915 in the MSDN Product Feedback Center.
(c) 2005, Adduxis. All rights reserved.