Using the following VB-syntax in a DataRepeater will no longer work after applying .NET Framework 2.0 Service Pack 1 in a medium-trust environment.
Use Eval-method, as recommended in all Microsoft documentation. Using explicit casting would work as well, but you'd have to re-write every page if you decide to change your data layer.
Create an ASP.NET page with a repeater using a simple OleDb database as it's DataSource.
If you run this application in full trust, you should encounter no problems.
Now, set the trust level to medium. (You'll have to modify the settings and give it access to OleDbConnections.) When you run it you'll get a Security Exception:
Visual Basic has always been strong on implicit casting. For example, this code is completely valid:
So, in the sample at the top, Container.DataItem is merely an Object. VB then casts this to a System.Data.Common.DbDataRecord object and we're able to retrieve the "data"-property. This is no longer working after Service Pack 1.
C, in all its variations wouldn't be caught dead accepting a syntax like String = Integer, so the code at the top would never work. Instead you'd have to explicitly cast the object to the appropriate type:
If you change the VB code so that it uses the VB equivalent: CType you will resolve the problem.
So, is the resolution to use explicit casting? Well, not really. If you look at the C# example above you might notice a potential problem. If we change our data layer we would have to go through every single page and change the explicit casting. This is one of the reasons why we've always recommended using the Databinder.Eval method for VB and C# alike, so if you've followed the design guidelines your code should look like this:
Actually, as of Framework 2.0 it's enough to write Eval("data").
So, if you review the documentation on msdn for Framework 1.1, Framework 2.0, knowledge base articles, etc. you'll see that we consistently recommend using the Eval method.
/ Johan