Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C# C#4.0 VB10.0 VB.NET Generics , +
Hi all,
I have found a rather annoying difference between calling generic Extension methods between VB and C#.
 
I have written some Extension methods in a library written in C#. I am referencing this in a VB program and in a C# program. The difference (and problem) is that calling the function works different in both languages...
 
Here is the Extension methods signature:
public static TEntityItem AsEntityItem<TEntityItem, TEntity>(this TEntity entity)
         where TEntityItem : EntityItem<TEntity>
         where TEntity : EntityObject
In my case I am creating some extensions to work with Entity Framework, but that doesn't really matter for my question.
 
In my programs I have an Entity called SalesOrderHeader and an EntityItem called SalesOrderItem.
Now when I call this function in VB it looks like follows:
Dim s As New SalesOrderHeader
Dim item = s.AsEntityItem(Of SalesOrderItem)()
This looks pretty neat. The code pretty much reads as plain text. Convert the SalesOrderHeader to a SalesOrderItem.
 
In C# this looks a little bit different...
SalesOrderHeader s = new SalesOrderHeader();
var item = s.AsEntityItem<OrderHeaderItem, SalesOrderHeader>();
Can you spot the difference? I have to give SalesOrderHeader as a type parameter, while I could leave this out in VB (it isn't even allowed in VB!).
 
I have a couple of Extension methods like this and the C# way of calling those tends to make the code bloated. Converting between VB and C# becomes impossible...
Is this an uneasy difference between the two languages or am I missing something?

 
UPDATE:
I have created a small sample project (three actually) for people to copy/paste and check it out.
 
In my first (C#) project I have created two classes and an Extension method.
They mimic the classes and methods mentioned above.
using System;
 
namespace WildWildWest
{
	public class Ammo { }
 
	public class Gun<TAmmo> where TAmmo : Ammo
	{ public TAmmo Ammo { get; set; } }
 
	public static class Extensions
	{
		public static TGun Load<TGun, TAmmo>(this TAmmo ammo)
			where TGun : Gun<TAmmo>
			where TAmmo : Ammo
		{
			TGun gun = Activator.CreateInstance<TGun>();
			gun.Ammo = ammo;
			return gun;
		}
	}
}
You can simply copy/paste and compile it. Now create a C# project and a VB project and reference the project with the Ammo (Entity in original question), Gun (EntityItem in original question) and the Extension method.
 
In your C# project you can copy/paste the following code:
using WildWildWest;
 
namespace CSharpTest
{
	public class BigAmmo : Ammo { }
	public class BigGun : Gun<BigAmmo> { }
 
	public class Test
	{
		private void SomeMethod()
		{
			BigAmmo ammo = new BigAmmo();
			// Doesn't work. Two type parameters are required.
			//BigGun gunWrong = ammo.Load<BigGun>();
			BigGun gun = ammo.Load<BigGun, BigAmmo>();
		}
	}
}
 
In your VB project you can copy/paste the following code:
Imports WildWildWest
 
Public Class BigAmmo
    Inherits Ammo
End Class
 
Public Class BigGun
    Inherits Gun(Of BigAmmo)
End Class
 
Public Class Test
    Private Sub SomeMethod()
        Dim ammo As New BigAmmo()
        Dim gun As BigGun = ammo.Load(Of BigGun)()
        ' Doesn't work. Only one type parameter allowed.
        'Dim gunWrong As BigGun = ammo.Load(Of BigGun, BigAmmo)()
    End Sub
End Class
Notice how VB only requires one type parameter where C# requires two?
The type of Ammo could be inferred from the type of Gun, yet C# doesn't.
Unfortunately I am using C# for my current project and my classes are called names like SalesOrderHeader. You can imagine things get pretty bloated when calling order.AsEntityItem<SalesOrderHeaderItem, SalesOrderHeader>()... I can live with a little bloated code though. What I can't live with is that C# appearently can't infer a type even when it's so obvious and VB can.
So, any idea why C# doesn't infer the type of Ammo or how I could make C# infer it anyway?
 
UPDATE 2:
My last example created some doubts concerning referencing wrong dll's or leaving out code.
So here is the COMPLETE code in C# and VB.
using System;
 
namespace WildWildWest
{
	public class Ammo { }
 
	public class Gun<TAmmo> where TAmmo : Ammo
	{ public TAmmo Ammo { get; set; } }
 
	public static class Extensions
	{
		public static TGun Load<TGun, TAmmo>(this TAmmo ammo)
			where TGun : Gun<TAmmo>
			where TAmmo : Ammo
		{
			TGun gun = Activator.CreateInstance<TGun>();
			gun.Ammo = ammo;
			return gun;
		}
	}
	public class BigAmmo : Ammo { }
	public class BigGun : Gun<BigAmmo> { }
 
	public class Test
	{
		private void SomeMethod()
		{
			BigAmmo ammo = new BigAmmo();
			// Still does not work...
			//BigGun gunWrong = ammo.Load<BigGun>();
			BigGun gun = ammo.Load<BigGun, BigAmmo>();
		}
	}
}
Public Class Ammo
End Class
 
Public Class Gun(Of TAmmo As Ammo)
    Public Property Ammo As TAmmo
End Class
 
Module Extensions
    <System.Runtime.CompilerServices.Extension()>
    Public Function Load(Of TGun As Gun(Of TAmmo), TAmmo As Ammo)(ByVal ammo As TAmmo) As TGun
        Dim gun As TGun = Activator.CreateInstance(Of TGun)()
        gun.Ammo = ammo
        Return gun
    End Function
End Module
 
Public Class BigAmmo
    Inherits Ammo
End Class
 
Public Class BigGun
    Inherits Gun(Of BigAmmo)
End Class
 
Public Class Test
    Private Sub SomeMethod()
        Dim ammo As New BigAmmo()
        ammo.Load(Of BigGun)()
        ' Still does not work...
        'ammo.Load(Of BigGun, BigAmmo)()
    End Sub
End Class
I have also checked the IL and they compile to the same IL. However when checking the compiled VB code and pasting it back it simply does not work because it uses C# notation...
Here's the IL:
.method private instance void  SomeMethod() cil managed
{
  // Code size       16 (0x10)
  .maxstack  1
  .locals init ([0] class ClassLibrary1.BigAmmo ammo)
  IL_0000:  nop
  IL_0001:  newobj     instance void ClassLibrary1.BigAmmo::.ctor()
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  call       !!0 ClassLibrary1.Extensions::Load<class ClassLibrary1.BigGun,class ClassLibrary1.BigAmmo>(!!1)
  IL_000d:  pop
  IL_000e:  nop
  IL_000f:  ret
} // end of method Test::SomeMethod
And here's the VB, gotten using Teleriks JustDecompile.
Public Class Test
    <DebuggerNonUserCode>
    Public Sub New()
        MyBase.New()
    End Sub
 
    Private Sub SomeMethod()
        Dim ammo As BigAmmo = New BigAmmo()
        ammo.Load(Of BigGun, BigAmmo)()
    End Sub
End Class
Of course ammo.Load(Of BigGun, BigAmmo)() does not work in VB...
 
Why is it possible for VB to leave out the type of TAmmo? Because TGun is already a type of Gun(Of TAmmo). So the type of TAmmo can be inferred from the type of TGun. In the above example TGun is BigGun(Of BigAmmo), so TAmmo can never be anything else but BigAmmo. VB understands this and says it's okay to just provide the type of TGun. C# does not and still requires me to explicitly type TAmmo...
Posted 30-Jan-13 3:30am
Edited 31-Jan-13 20:23pm
v3
Comments
Sergey Alexandrovich Kryukov at 30-Jan-13 12:35pm
   
How come you have two generic parameters in C# but trying to write just one in instantiation of generic in VB.NET?
 
I think the difference is only the syntax...
—SA
Naerling at 30-Jan-13 13:33pm
   
I'm not TRYING to write only one in VB.NET, I'm FORCED to write only one in VB.NET.
Appearently VB.NET can infer the type of TEntity since it's the same as the type of TEntity in TEntityItem.
C#, however, can't infer the type and you have to specify it.
This just struck me as odd since there is no reason why C# can't infer it while VB can.
Not having to type in the type which is already exposed in TEntityItem seems logical to me and gives quite a bit of comfort and cleaner code.
Sergey Alexandrovich Kryukov at 30-Jan-13 13:50pm
   
You are never forced to use inferences, and, in more complex cases, I would recommend not to use it...
Now, how are you forced? VB.NET uses multiple generic parameters exactly as C#.
—SA
Naerling at 30-Jan-13 15:19pm
   
VB.NET simply says there's only one type parameter, which is TEntityItem. Whenever I specify the type of TEntity it gives an error saying there is only one type parameter.
In C# I have the exact opposite. I have to specify two and if I only specify one it gives me the error that there is no constructor with only one type parameter.
 
I find it very confusing that VB.NET and C# work so differently at this point. That's why I thought I might be missing something.
Sergey Alexandrovich Kryukov at 30-Jan-13 16:39pm
   
I doubt it...
I think C# and VB.NET are structurally and functionally equivalent at this point; and you are missing exactly this...
—SA
Naerling at 30-Jan-13 17:44pm
   
I'll double check this tomorrow, but I'm positively sure there's a difference between VB and C# here. I didn't believe it today until I re-build and re-referenced all my assemblies in both VB and C# projects. Tomorrow I'll even give you some sample code if I can reproduce it.
Naerling at 31-Jan-13 17:19pm
   
I have added some code in my question for you to copy/paste.
Go and see for yourself that C# really DOES work differently than VB at this point.
 
Before yesterday I would've said the same as you, "VB and C# are equivalent at this point". Imagine my surprise :-)
Sergey Alexandrovich Kryukov at 31-Jan-13 17:21pm
   
Thank you very much. I would be surprised, but good to know. Let me see...
—SA
Sergey Alexandrovich Kryukov at 31-Jan-13 17:28pm
   
What are you talking about?!
Here a simple case of two parameters, dictionary key and value types:
http://msdn.microsoft.com/en-us/library/xfhwa508.aspx?cs-save-lang=1&cs-lang=vb#code-snippet-1
 
Now, click C# and VB.NET language tabs and compare. Do the same with code samples. Same thing, isn't it? As to your example, this is what not convincing in it: you don't show the definition of Load. How can you see that you use absolutely the same definition in both cases? Huh? Perhaps you messed up something with the syntax in a fragment you did not show...
 
—SA
Naerling at 31-Jan-13 17:45pm
   
The Dictionary case is something completely different... There are no type constraints on TKey and TValue, so TValue could never be inferred from TKey (or vice versa).
In my example I have given a type constraint on both TGun and TAmmo. Since TGun should be a type of Gun TAmmo could always be inferred from TGun.
And actually I have given you code where you can see VB does exactly that, infer the type of TAmmo.
I have not only shown you the definiton of Load, I have shown you what it does, I have shown you Ammo, Gun and how to use the extension method in both VB and C#...
 
I have tested this with just the code you see above and I am VERY sure there is ONLY ONE definition of Load... There are absolutely no fragments I am not showing you.
You can copy/paste all of the code above and see for yourself that it does, in fact, work differently for C# and VB...
Sergey Alexandrovich Kryukov at 31-Jan-13 18:18pm
   
OK, you need to show a totally complete project, otherwise this talk is ineffective. And please keep in mind that I don't have and don't want add VB.NET to installation.
OK, I understand, there can be type constraints, so what?
Do you also understand that you can reference absolutely any assembly in C# in VB.NET project, and it should perfectly match?.. this is not a simple syntax mish-mash, to allow discrepancy (like in, say, anonymous methods where VB.NET went behind C#); syntax is different but CIL matches...
By the way, you can also look at resulting IL and compare...
—SA
Sergey Alexandrovich Kryukov at 30-Jan-13 13:50pm
   
Let me ask you unrelated question: do you really use VB.NET? Why?
—SA
Naerling at 30-Jan-13 15:23pm
   
Because it's the first language I learned at my job where everyone codes VB.NET. I actually prefer it over C# which, to me, sometimes reads like {{{{{{}}}}}}}} :-)
Let me ask you a counter question. Why are you NOT using it? It can do everything C# does. Sometimes a bit less, sometimes a bit more and sometimes a bit differently. To me it's mostly a matter of syntax. And I slightly prefer VB syntax over C# syntax. Probably because it's my first language.
Sergey Alexandrovich Kryukov at 30-Jan-13 16:38pm
   
I agree, VB.NET readability is better. The trouble is: it is not going to become a standard. And C# is a strict ECMA and even ISO standard...
The only goal of VB.NET is to keep VB users busy, quite frankly...
—SA
Naerling at 30-Jan-13 17:39pm
   
I don't know much about ISO and ECMA. I'm not bothered by standards to much... If millions of users worldwide have used VB for more than two decades then who is ISO or ECMA to say that it's not a standard? Not being a standard hasn't stopped VB or its users from delivering software to customers and solving many problems and, more importantly than any standard in the world, making customers happy. So as standards is concerned I see no problem.
 
But I also believe each programmer should at least know C-based syntax, such as C# or Java. I am as proficient with C# as I am with VB. I recently read some C++ code samples (a language I've never used) and I didn't realize it until the fourth sample or so. Many code samples on the internet are C# too. VB is hard to find, so it's almost a must to know C# anyway.
 
My only problem with VB is that many of its users come from a time when OOP was not standard yet. And many modern VB code is written exactly like that too. WinForms with thousands lines of code, 'safe' casting functions that simply concatenate empty strings to any object, on error resume nexts, gotos, lots of global variables etc... Especially old VB code is often a mess like that. Often even ported from VB1 to VB2... All the way to VB.NET. VB.NET has a history and it shows. If only in the attitude people have towards VB.
I think such an attitude to any serious language is misplaced though. A language is merely a tool and as good or bad as the programmer using it. I've seen C# code that is just as messy.
 
I must admit that I've been using C# quite intensively lately and I'm beginning to like it a bit more than before :-)
BC @ CV at 1-Feb-13 17:59pm
   
I totally agree. I started in VB6 and when .Net came along I spent about 3 months with VB.Net then dropped it for C# and haven't looked back. The IL maybe the same but C# is the more respected language perhaps because its stricter and because of VB6 bagage. I also prefer the less verbose language since I can scan the code quicker.
Naerling at 1-Feb-13 18:24pm
   
I think the disrespect for VB is a bit unfair... You should ask yourself if C# and .NET would've been so awesome if VB1-6 hadn't been around :-)
BC @ CV at 4-Feb-13 9:17am
   
If VB1-6 hadn't been around there would not be a VB.Net & C# would still be what it is today. VB.Net was created for the sole purpose of retaining the VB6 users. VB1-6 was a good product that fulfilled a need. It made rapid application development in businesses possible to a degree that no other platform did. When I first started coding in VB6 I loved it. It was easy to learn and I could quickly assemble fully functional applications. Anyway, C#, VB, C++, PHP, etc are all just a means to an end.

1 solution

Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

OK, I know what do to with you. Even if you are were not convinced by my clear example of System.Collection.Generic.Dictionary (you started to argument that the generic parameters are not constrained), I'll better show you a right method of research which you can use by yourself and remove all doubts. You did not provide a comprehensive complete sample, so I'll do it for you.
 
I'll start with some minimalistic C# samples, with two generic parameters, and with generic parameter constraints:
using System;
 
namespace MultipleGenericParameters {
 
    public class SomethingDisposable : System.IDisposable {
        void System.IDisposable.Dispose() { }
    } //class SomethingDisposable

    public class Test {
        public static void GenericMethod<First, Second>(First first, Second second)
            where First: System.IDisposable
            where Second: new() { }
        public static void GenericMethodCaller() {
            GenericMethod<SomethingDisposable, System.Text.StringBuilder>(
                new SomethingDisposable(),
                new System.Text.StringBuilder());
        } //GenericMethodCaller
    } // class Text

    class Program {
        static void Main(string[] args) {
        } //Main
    } //class Program

} //namespace MultipleGenericParameters
 
Clear enough, isn't it?
 
For the rest of it, we will need an open-source tool, ILSpy:
http://ilspy.net/[^],
http://en.wikipedia.org/wiki/.NET_Reflector[^].
 
Get it, open, but better compile by yourself. Reflector, presently commercial, can also be used, if you have this product.
 
Compile the above code and decompile it to VB.NT. You will get:
Imports System
Imports System.Text
 
Namespace MultipleGenericParameters
 
    Public Class SomethingDisposable
        Implements IDisposable
        Sub Dispose() Implements IDisposable.Dispose
        End Sub
    End Class
 
    Public Class Test
        Public Shared Sub GenericMethod(Of First As IDisposable, Second As New)(first As First, second As Second)
        End Sub
 
        Public Shared Sub GenericMethodCaller()
            Test.GenericMethod(Of SomethingDisposable, StringBuilder)(New SomethingDisposable(), New StringBuilder())
        End Sub
    End Class
 
End Namespace
 
As you can see, two generic parameters with generic parameter constraint fit nicely in VB.NET. Now, you can compile it, add some test code, run it — I bet it works.
 
You an even "invent" more arguments against VB.NET, but now you have no excuses: you should compile your code, decompile it and make sure it is valid in the different language. Moreover, you can test, and, importantly, decompile it to CIL to IL:
 
MultipleGenericParameters.Test:
.class public auto ansi beforefieldinit MultipleGenericParameters.Test
	extends [mscorlib]System.Object
{
	// Methods
	.method public hidebysig static 
		void GenericMethod<([mscorlib]System.IDisposable) First, .ctor Second> (
			!!First first,
			!!Second second
		) cil managed 
	{
		// Method begins at RVA 0x205b
		// Code size 2 (0x2)
		.maxstack 8
 
		IL_0000: nop
		IL_0001: ret
	} // end of method Test::GenericMethod

	.method public hidebysig static 
		void GenericMethodCaller () cil managed 
	{
		// Method begins at RVA 0x205e
		// Code size 18 (0x12)
		.maxstack 8
 
		IL_0000: nop
		IL_0001: newobj instance void MultipleGenericParameters.SomethingDisposable::.ctor()
		IL_0006: newobj instance void [mscorlib]System.Text.StringBuilder::.ctor()
		IL_000b: call void MultipleGenericParameters.Test::GenericMethod<class MultipleGenericParameters.SomethingDisposable, class [mscorlib]System.Text.StringBuilder>(!!0, !!1)
		IL_0010: nop
		IL_0011: ret
	} // end of method Test::GenericMethodCaller

	.method public hidebysig specialname rtspecialname 
		instance void .ctor () cil managed 
	{
		// Method begins at RVA 0x2071
		// Code size 7 (0x7)
		.maxstack 8
 
		IL_0000: ldarg.0
		IL_0001: call instance void [mscorlib]System.Object::.ctor()
		IL_0006: ret
	} // end of method Test::.ctor

} // end of class MultipleGenericParameters.Test
 
MultipleGenericParameters.SomethingDisposable:
.class public auto ansi beforefieldinit MultipleGenericParameters.SomethingDisposable
	extends [mscorlib]System.Object
	implements [mscorlib]System.IDisposable
{
	// Methods
	.method private final hidebysig newslot virtual 
		instance void System.IDisposable.Dispose () cil managed 
	{
		.override method instance void [mscorlib]System.IDisposable::Dispose()
		// Method begins at RVA 0x2050
		// Code size 2 (0x2)
		.maxstack 8
 
		IL_0000: nop
		IL_0001: ret
	} // end of method SomethingDisposable::System.IDisposable.Dispose

	.method public hidebysig specialname rtspecialname 
		instance void .ctor () cil managed 
	{
		// Method begins at RVA 0x2053
		// Code size 7 (0x7)
		.maxstack 8
 
		IL_0000: ldarg.0
		IL_0001: call instance void [mscorlib]System.Object::.ctor()
		IL_0006: ret
	} // end of method SomethingDisposable::.ctor

} // end of class MultipleGenericParameters.SomethingDisposable
 
You can even make a round trip: compiler both VB.NET and C# projects, make sure they compile, decompile into IL. Try to find differences. In this very case, you won't.
 
Is that finally end of story? If not, take your code and repeat the procedure.
 
[EDIT #1]
 
I cannot believe I advocate VB.NET! Yes, this language probably has no chance to become a standard, it has a heavy legacy of some really moronic predecessor "languages" (quotation marks intended), it is hardly taken seriously by serious developers; and I never allow myself to install it on my computers…
 
But — it's important to be fair and keep to pure facts. Generics in this language is not a failure. Smile | :)
 
[EDIT #2]
 
Thank you for clarification. I got your updated, complete code. First of all, C# comments
// Still does not work...
//BigGun gunWrong = ammo.Load<BigGun>();
could rather read "of course it should not compile". Smile | :)
 
Now, I compiled all your code converted to VB.NET and got as expected:
 
Imports System
Namespace WildWildWest
 
   Public Module Extensions
      <System.Runtime.CompilerServices.ExtensionAttribute()>
      Public Function Load(Of TGun As Gun(Of TAmmo), TAmmo As Ammo)
            (ammo As TAmmo) As TGun
         Dim gun As TGun = Activator.CreateInstance(Of TGun)()
         gun.Ammo = ammo
         Return gun
      End Function
   End Module
 
   Public Class Test
      Private Sub SomeMethod()
         Dim ammo As BigAmmo = New BigAmmo()
         Dim gun As BigGun = ammo.Load(Of BigGun, BigAmmo)()
      End Sub
   End Class
 
End Namespace
 
Any problem with that?
 
Good luck,
—SA
  Permalink  
v4
Comments
Naerling at 1-Feb-13 2:29am
   
Thanks for your example. Unfortunately it's still not accurate. You have added type constraints, but the contraint on First does not include Second, so Second can never be inferred from First... In my example TGun is always of type Gun(Of TAmmo), so if TGun is BigGun which is a Gun(Of BigAmmo) then TAmmo can never be anything else than BigAmmo. VB understands this, C# does not.
In your example, if First is SomethingDisposable that still says nothing about Second. So both C# and VB cannot infer the type of Second.
 
I have updated my question with a full C# and VB example and IL (which is the same for both languages, cannot correctly roundtrip to VB).
Sergey Alexandrovich Kryukov at 1-Feb-13 2:36am
   
No, no... What a minute... I explained to you: no more excuses.
 
I explained you the method, now it's your turn. Write down your code, whatever you think is accurate. Do the same. Show me the C# code... You never did it so far, but now you can see why. Isn't that fair?
 
I can say what is unfair: you are using arguments which are not valid in terms of defalsification. This is the idea: no matter what I right, you can always say "it's not accurate". Can you see the point? So, to be fair and constructive, from the standpoint of getting the truth, you should right the C# code disproving the point. Obvious logic...
 
Now I see, you also need inference. But inference is a language-specific "trick", it does not exist in .NET itself. So, please, write equivalent code without inference. Or use inference, I don't mind. It just does not matter at all. VB.NET will allow you to use two generic parameters anyway...
 
You write the complete code sample to argue against my statements. In confirm or proof the opposite. Before you do, there is nothing to discuss. OK?
 
—SA
Naerling at 1-Feb-13 4:29am
   
I don't understand what you mean. In your example C# and VB work exactly the same and I can't prove differently. However, in my sample, which is pretty different from yours, C# and VB DO work differently yet you say they don't. So far you have not backed up your claims or proven me wrong. VB.NET will NOT allow me to use two generic parameters and C# WILL force me to use two. I have given you my code sample to prove that VB and C# work differently in inferring generic types. I don't really care that the same IL is emitted. I code in C# or VB, not IL.
Sergey Alexandrovich Kryukov at 1-Feb-13 10:57am
   
What you don't understand? If you think my example is inadequate, test on another one. You never really shown your sample, but if you have it and it compiles, please no prove yourself that the problem really exist, on your sample. I foresee that the problem will disappear when you do it all to the end... Just try.
—SA
Naerling at 1-Feb-13 11:05am
   
Have you seen my updated question? I have coded an entire sample in VB and C# and shown the differences. It compiles perfectly and you can test it yourself by copy/pasting. Of course you will need VB to test it in VB yourself...
So what I don't understand is why my example isn't good for you and why it should work?
Sergey Alexandrovich Kryukov at 1-Feb-13 12:30pm
   
Oh, wait a second... It there a complete example? In C#? (As you claim VB.NET does not work, it should be C#.) From what line to what?
Sorry if I missed it.
—SA
Naerling at 1-Feb-13 14:03pm
   
I don't know what line exactly, but there are a few code blocks in my question. It should be one of them. Right under 'UPDATE 2'.
Sergey Alexandrovich Kryukov at 1-Feb-13 15:10pm
   
Oh, now we are talking.
Give me few minutes...
—SA
Sergey Alexandrovich Kryukov at 1-Feb-13 15:27pm
   
This is a more complex, but because of yest another thing, the extension methods.
Please see what I got, after [EDIT #2]. Again, two generic parameters...
—SA
Naerling at 1-Feb-13 17:13pm
   
Now we're getting to the problem... Which is the following line of code:
 
Dim gun As BigGun = ammo.Load(Of BigGun, BigAmmo)()
 
That does NOT compile. I repeat, does >>>NOT<<< compile.
VB only takes one type parameter, so it should have been the following:
 
Dim gun As BigGun = ammo.Load(Of BigGun)()
 
This line of code is exactly what I would have expected in C# too. Since ammo.Load(Of BigGun) could NEVER be of another Ammo type than BigAmmo (because BigGun is a Gun(Of BigAmmo) and not another Ammo). If you know what I mean...
Sergey Alexandrovich Kryukov at 1-Feb-13 17:29pm
   
Hm... Let me see...
—SA
jibesh at 1-Feb-13 18:40pm
   
@SA - got a busy weekend Sergey :-) need a helping hand?
Sergey Alexandrovich Kryukov at 1-Feb-13 18:52pm
   
I would highly appreciate it, absolutely.
 
You see, I'm still not convinced that the situation (absolutely problem-fee writh C#) with VB.NET is that bad as Naerling describes (would be a real disaster).
I don't want to install VB.NET to Studio, something that I never do, but we all have a compiler. It would be good to finally sort it out...
 
—SA
jibesh at 1-Feb-13 18:58pm
   
same here. I never ever install VB.Net in my personal computer of even Office computer if it was me who installs Studio. unfortunately I have VB.Net installed to my office laptop by the IT guys. so will have a quick look at this problem in my weekends and keep checking this just in case someone solved this mystery case.
Sergey Alexandrovich Kryukov at 1-Feb-13 19:36pm
   
VB.NET itself is always "installed", it's a part of .NET. How else CodeDOM would work? :-)
Thanks goodness, I never worked in the office where "IT guys" dare to tell me what to use for development...
—SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 Sergey Alexandrovich Kryukov 580
1 ashok rathod 159
2 CPallini 140
3 CHill60 130
4 BillWoodruff 125
0 Sergey Alexandrovich Kryukov 9,543
1 OriginalGriff 6,984
2 CPallini 5,820
3 George Jonsson 4,017
4 Gihan Liyanage 3,266


Advertise | Privacy | Mobile
Web03 | 2.8.140926.1 | Last Updated 1 Feb 2013
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100