Is this a bug... a big one?
| Author |
Message |
|
Zorie
#1 / 15
|
 Is this a bug... a big one? Ok so we are told that you can have components written in different languages.... I had a VB project and I inserted a C# class, which was a {*filter*}, because VB
didn't want me to insert a C# class. When I tried to compile the compiler
went nuts.
Now I know that I can compile the project correctly by had with NMAKE, but
why is it that Visual Studio is not recognizing that .vb should be compiled
through one compiler and .cs should be compiled through another.
If we are truly going to be working with classes of other languages within
our projects, which is really kewl, then the editor should know that it must
compile them based on extension.
Thoughts?
-V-
|
| Thu, 29 May 2003 11:03:33 GMT |
|
 |
|
Jeff Pei
#2 / 15
|
Is this a bug... a big one? Hi Victoria, I believe you need to create a solution(workspace) containing two projects.
This is really no different than setting up different makefile rules for
different extensions. When you build the solution it should build all of
the contained projects. It's probably best to think of the solution as your
makefile and each project in the solution as a build-target.
Quote: > Ok so we are told that you can have components written in different > languages.... > I had a VB project and I inserted a C# class, which was a {*filter*}, because
VB
> didn't want me to insert a C# class. When I tried to compile the compiler
> went nuts.
> Now I know that I can compile the project correctly by had with NMAKE, but
> why is it that Visual Studio is not recognizing that .vb should be
compiled
> through one compiler and .cs should be compiled through another.
> If we are truly going to be working with classes of other languages within
> our projects, which is really kewl, then the editor should know that it
must
> compile them based on extension.
> Thoughts?
> -V-
|
| Thu, 29 May 2003 13:13:34 GMT |
|
|
|
Jonathan Alle
#3 / 15
|
Is this a bug... a big one? Each "Project" compiles to a single file. Since there isn't a cross-language compiler, you'll have to put them in separate projects. --
Jonathan Allen
Quote: > Ok so we are told that you can have components written in different > languages.... > I had a VB project and I inserted a C# class, which was a {*filter*}, because
VB
> didn't want me to insert a C# class. When I tried to compile the compiler
> went nuts.
> Now I know that I can compile the project correctly by had with NMAKE, but
> why is it that Visual Studio is not recognizing that .vb should be
compiled
> through one compiler and .cs should be compiled through another.
> If we are truly going to be working with classes of other languages within
> our projects, which is really kewl, then the editor should know that it
must
> compile them based on extension.
> Thoughts?
> -V-
|
| Thu, 29 May 2003 12:24:03 GMT |
|
|
|
Zorie
#4 / 15
|
Is this a bug... a big one? But if I do that then I do not have one exe. In a make file I can compile each class with the compiler for that language
and then link the libraries. I would assume they would have that built in.
If we can write a class in C# and inherit from it in VB.Net I would suspect
that I could have them contained in the same assembly.
For the first time we have an easy way to use cross-language components. I
should have the ability to download a C# class and a COBOL.Net class (along
with the compiler) and have My single assembly compiled from within a
project. All that needs to be done is a file extension associated with a
compiler.
I'll write an example and post it here to be more clear on what I am trying
to accomplish. If this feature is added to VStudio or fixed (which ever is
the case) it will be one of the largest marketing items the compiler
manufacturers will have.... ever.
I hope I am not going to be disappointed here. lol
-V-
Quote: > Hi Victoria, > I believe you need to create a solution(workspace) containing two
projects.
> This is really no different than setting up different makefile rules for
> different extensions. When you build the solution it should build all of
> the contained projects. It's probably best to think of the solution as
your
> makefile and each project in the solution as a build-target.
> > Ok so we are told that you can have components written in different
> > languages....
> > I had a VB project and I inserted a C# class, which was a {*filter*}, because
> VB
> > didn't want me to insert a C# class. When I tried to compile the
compiler
> > went nuts.
> > Now I know that I can compile the project correctly by had with NMAKE,
but
> > why is it that Visual Studio is not recognizing that .vb should be
> compiled
> > through one compiler and .cs should be compiled through another.
> > If we are truly going to be working with classes of other languages
within
> > our projects, which is really kewl, then the editor should know that it
> must
> > compile them based on extension.
> > Thoughts?
> > -V-
|
| Thu, 29 May 2003 14:05:12 GMT |
|
|
|
Jeff Pei
#5 / 15
|
Is this a bug... a big one? Hi Victoria,
Quote: > But if I do that then I do not have one exe.
You can't get one exe from the commandline either. Quote: > In a make file I can compile each class with the compiler for that
language
> and then link the libraries. I would assume they would have that built
in.
> If we can write a class in C# and inherit from it in VB.Net I would
suspect
> that I could have them contained in the same assembly.
You can get them contained in one assembly (though IIRC the IDE won't support this) but only as a multi-file assembly (that is an assembly made up of two modules.) Quote: > For the first time we have an easy way to use cross-language components.
I
> should have the ability to download a C# class and a COBOL.Net class
(along
> with the compiler) and have My single assembly compiled from within a
> project. All that needs to be done is a file extension associated with a
> compiler.
Actually more then that would be needed. You'll notice that neither the vbc or csc compiler supports emitting anything other than an .exe or .dll (specifically it will not emit a .obj file.) The C# and VB.NET compilers do not go through a traditional link phase, and as such there is no easy way to combine the output from the two compilers into a single PE file. Quote: > I'll write an example and post it here to be more clear on what I am
trying
> to accomplish. If this feature is added to VStudio or fixed (which ever
is
> the case) it will be one of the largest marketing items the compiler
> manufacturers will have.... ever.
It would be pretty cool, but personally I think that an assembly made up of multiple modules is good enough for V1. It allows for variables with the internal access level to be shared across classes compiled in differing languages that are stored in a single assembly, so the only downside is that you end up with multiple PE files for the assembly. Quote: > I hope I am not going to be disappointed here. lol
There have been indications that this might make it into V2, but it has been explicitly stated that it won't be in V1 (that is, at least support from the command line compilers.)
|
| Thu, 29 May 2003 14:24:32 GMT |
|
|
|
--==[ russ ]==-
#6 / 15
|
Is this a bug... a big one? Why not have an actual Assembly file type? It would be much easier for transport to just copy the ".assembly" file around. --
--------
Russ
Quote: > Hi Victoria,
> > But if I do that then I do not have one exe.
> You can't get one exe from the commandline either.
> > In a make file I can compile each class with the compiler for that
> language
> > and then link the libraries. I would assume they would have that built
> in.
> > If we can write a class in C# and inherit from it in VB.Net I would
> suspect
> > that I could have them contained in the same assembly.
> You can get them contained in one assembly (though IIRC the IDE won't
> support this) but only as a multi-file assembly (that is an assembly made
up
> of two modules.)
> > For the first time we have an easy way to use cross-language components.
> I
> > should have the ability to download a C# class and a COBOL.Net class
> (along
> > with the compiler) and have My single assembly compiled from within a
> > project. All that needs to be done is a file extension associated with
a
> > compiler.
> Actually more then that would be needed. You'll notice that neither the
vbc
> or csc compiler supports emitting anything other than an .exe or .dll
> (specifically it will not emit a .obj file.) The C# and VB.NET compilers
do
> not go through a traditional link phase, and as such there is no easy way
to
> combine the output from the two compilers into a single PE file.
> > I'll write an example and post it here to be more clear on what I am
> trying
> > to accomplish. If this feature is added to VStudio or fixed (which ever
> is
> > the case) it will be one of the largest marketing items the compiler
> > manufacturers will have.... ever.
> It would be pretty cool, but personally I think that an assembly made up
of
> multiple modules is good enough for V1. It allows for variables with the
> internal access level to be shared across classes compiled in differing
> languages that are stored in a single assembly, so the only downside is
that
> you end up with multiple PE files for the assembly.
> > I hope I am not going to be disappointed here. lol
> There have been indications that this might make it into V2, but it has
been
> explicitly stated that it won't be in V1 (that is, at least support from
the
> command line compilers.)
|
| Thu, 29 May 2003 14:45:17 GMT |
|
|
|
Zorie
#7 / 15
|
Is this a bug... a big one? Ok so when I write lets say Item.cs and compile it as csc t:/module Item.cs
I don't have a way to embed it into the assembly of another language.
Because according to the compilers vb and csc t:/module creates a module to
be INCLUDED in another assembly.
I have successfully made the module and linked it to vb and it worked, now I
am going to figure out how to insert it into the assembly.
-V-
Quote: > Hi Victoria,
> > But if I do that then I do not have one exe.
> You can't get one exe from the commandline either.
> > In a make file I can compile each class with the compiler for that
> language
> > and then link the libraries. I would assume they would have that built
> in.
> > If we can write a class in C# and inherit from it in VB.Net I would
> suspect
> > that I could have them contained in the same assembly.
> You can get them contained in one assembly (though IIRC the IDE won't
> support this) but only as a multi-file assembly (that is an assembly made
up
> of two modules.)
> > For the first time we have an easy way to use cross-language components.
> I
> > should have the ability to download a C# class and a COBOL.Net class
> (along
> > with the compiler) and have My single assembly compiled from within a
> > project. All that needs to be done is a file extension associated with
a
> > compiler.
> Actually more then that would be needed. You'll notice that neither the
vbc
> or csc compiler supports emitting anything other than an .exe or .dll
> (specifically it will not emit a .obj file.) The C# and VB.NET compilers
do
> not go through a traditional link phase, and as such there is no easy way
to
> combine the output from the two compilers into a single PE file.
> > I'll write an example and post it here to be more clear on what I am
> trying
> > to accomplish. If this feature is added to VStudio or fixed (which ever
> is
> > the case) it will be one of the largest marketing items the compiler
> > manufacturers will have.... ever.
> It would be pretty cool, but personally I think that an assembly made up
of
> multiple modules is good enough for V1. It allows for variables with the
> internal access level to be shared across classes compiled in differing
> languages that are stored in a single assembly, so the only downside is
that
> you end up with multiple PE files for the assembly.
> > I hope I am not going to be disappointed here. lol
> There have been indications that this might make it into V2, but it has
been
> explicitly stated that it won't be in V1 (that is, at least support from
the
> command line compilers.)
|
| Thu, 29 May 2003 15:51:18 GMT |
|
|
|
Jeff Pei
#8 / 15
|
Is this a bug... a big one?
Quote: > Why not have an actual Assembly file type? It would be much easier for
> transport to just copy the ".assembly" file around.
Err, if you are asking why should they support multifile assemblies, I think the most obvious reason is internationalization (for example allowing your assembly to dynamically load a localized module as needed) As to supporting linking MSIL code compiled from multiple languages being
linked into a single file, I'd agree with you that it would be nice, but I
really don't see any reason why a new file format would make it any easier
to do this.
|
| Thu, 29 May 2003 16:04:47 GMT |
|
|
|
Jeff Pei
#9 / 15
|
Is this a bug... a big one? Hi Victoria, In can be included in another assembly at that point, but that doesn't mean
that the module will be physically included, rather it's metadata will be
included in the assembly's manifest (you are create an assembly made up of
multiple modules)
So, if you: execute "csc /t:module Item.cs" (generating the module
"Item.dll"), then execute "csc /t:exe /addmodule:item.dll Main.cs" you get
the assembly "Main.exe" which includes the metadate for the module
"Item.dll" in it's manifest (and the metadata/IL from "Item.dll" is
considered a part of the "Main.exe" assembly.) The code in Item.dll is still
stored seperately and must be transported along with "Main.exe"
One nice benefit of a multimodule assembly is that the modules are only
loaded when they are needed (so breaking a large assembly with portions that
aren't likely to be needed into multiple modules could let you optimize both
the load time, and the memory demands of the assembly.)
Quote: > Ok so when I write lets say Item.cs and compile it as > csc t:/module Item.cs
> I don't have a way to embed it into the assembly of another language.
> Because according to the compilers vb and csc t:/module creates a module
to
> be INCLUDED in another assembly.
> I have successfully made the module and linked it to vb and it worked, now
I
> am going to figure out how to insert it into the assembly.
|
| Thu, 29 May 2003 17:03:39 GMT |
|
|
|
michk
#10 / 15
|
Is this a bug... a big one? On the other hand, in the absence of actual tools to permit localization, this is not a terribly high priority (and querying of the top localization tool providers has yet to discern any who have made plans to support the format!). Even if there were such tools, this does have the feel of doing localization
work through activex dlls, rather that resource only dlls, in prior
versions -- more overhead than may truly be wanted for the job.
--
MichKa
a new book on internationalization in VB at
http://www.i18nWithVB.com/
Quote:
> > Why not have an actual Assembly file type? It would be much easier for
> > transport to just copy the ".assembly" file around.
> Err, if you are asking why should they support multifile assemblies, I
think
> the most obvious reason is internationalization (for example allowing your
> assembly to dynamically load a localized module as needed)
> As to supporting linking MSIL code compiled from multiple languages being
> linked into a single file, I'd agree with you that it would be nice, but I
> really don't see any reason why a new file format would make it any easier
> to do this.
|
| Thu, 29 May 2003 20:18:24 GMT |
|
|
|
Mattias Sj?gr
#11 / 15
|
Is this a bug... a big one? Unfortunately, creating multifile assemblies in VB only seems to be
impossible right now, since it lacks an /addmodule parameter.
Matt
============================================
|
| Thu, 29 May 2003 20:40:03 GMT |
|
|
|
Miguel Santo
#12 / 15
|
Is this a bug... a big one? .assembly seems a bit too long, perhaps just .ass ? :) Best Regards,
Miguel Santos
--==[ russ ]==-- escreveu na mensagem ...
Quote: >Why not have an actual Assembly file type? It would be much easier for >transport to just copy the ".assembly" file around. >--
>--------
>Russ
>> Hi Victoria,
>> > But if I do that then I do not have one exe.
>> You can't get one exe from the commandline either.
>> > In a make file I can compile each class with the compiler for that
>> language
>> > and then link the libraries. I would assume they would have that built
>> in.
>> > If we can write a class in C# and inherit from it in VB.Net I would
>> suspect
>> > that I could have them contained in the same assembly.
>> You can get them contained in one assembly (though IIRC the IDE won't
>> support this) but only as a multi-file assembly (that is an assembly made
>up
>> of two modules.)
>> > For the first time we have an easy way to use cross-language
components.
>> I
>> > should have the ability to download a C# class and a COBOL.Net class
>> (along
>> > with the compiler) and have My single assembly compiled from within a
>> > project. All that needs to be done is a file extension associated with
>a
>> > compiler.
>> Actually more then that would be needed. You'll notice that neither the
>vbc
>> or csc compiler supports emitting anything other than an .exe or .dll
>> (specifically it will not emit a .obj file.) The C# and VB.NET compilers
>do
>> not go through a traditional link phase, and as such there is no easy way
>to
>> combine the output from the two compilers into a single PE file.
>> > I'll write an example and post it here to be more clear on what I am
>> trying
>> > to accomplish. If this feature is added to VStudio or fixed (which
ever
>> is
>> > the case) it will be one of the largest marketing items the compiler
>> > manufacturers will have.... ever.
>> It would be pretty cool, but personally I think that an assembly made up
>of
>> multiple modules is good enough for V1. It allows for variables with the
>> internal access level to be shared across classes compiled in differing
>> languages that are stored in a single assembly, so the only downside is
>that
>> you end up with multiple PE files for the assembly.
>> > I hope I am not going to be disappointed here. lol
>> There have been indications that this might make it into V2, but it has
>been
>> explicitly stated that it won't be in V1 (that is, at least support from
>the
>> command line compilers.)
|
| Thu, 29 May 2003 22:33:37 GMT |
|
|
|
Zorie
#13 / 15
|
Is this a bug... a big one? Well this is now my biggest disappointment in DotNet. I would have given into all the other bull with the product if it could finally have released everyone from relying on a single language and allowed us to download class files from other language and use them. This is what they hinted at in their marketing material. So now I am pissed. (American Pissed/Mad)
-V-
Quote: > Hi Victoria, > In can be included in another assembly at that point, but that doesn't
mean
> that the module will be physically included, rather it's metadata will be
> included in the assembly's manifest (you are create an assembly made up of
> multiple modules)
> So, if you: execute "csc /t:module Item.cs" (generating the module
> "Item.dll"), then execute "csc /t:exe /addmodule:item.dll Main.cs" you get
> the assembly "Main.exe" which includes the metadate for the module
> "Item.dll" in it's manifest (and the metadata/IL from "Item.dll" is
> considered a part of the "Main.exe" assembly.) The code in Item.dll is
still
> stored seperately and must be transported along with "Main.exe"
> One nice benefit of a multimodule assembly is that the modules are only
> loaded when they are needed (so breaking a large assembly with portions
that
> aren't likely to be needed into multiple modules could let you optimize
both
> the load time, and the memory demands of the assembly.)
> > Ok so when I write lets say Item.cs and compile it as
> > csc t:/module Item.cs
> > I don't have a way to embed it into the assembly of another language.
> > Because according to the compilers vb and csc t:/module creates a module
> to
> > be INCLUDED in another assembly.
> > I have successfully made the module and linked it to vb and it worked,
now
> I
> > am going to figure out how to insert it into the assembly.
|
| Fri, 30 May 2003 01:29:32 GMT |
|
|
|
michk
#14 / 15
|
Is this a bug... a big one?
Quote: > Well this is now my biggest disappointment in DotNet. I would have given
> into all the other bull with the product if it could finally have released
> everyone from relying on a single language and allowed us to download
class
> files from other language and use them.
Victoria, no offense, but you already had given into all the other bull and had made broad proclomations about how you were as a company investing 100% in dotnet, on the basis of PDC and beta1 information. Even when people were suggesting slowing down? Quote: > This is what they hinted at in their marketing material.
I do not recall them hinting at anything beyond what is available.... I think wishful thinking played a part in this. Quote: > So now I am pissed. (American Pissed/Mad)
S'ok, it seems everyone will have their own pet peeve about it. A *real* marketing line would be: "It's cool as hell, but _____________________"
where everyone fills in the blank differently. Even the biggest of the
detractors could go along with that.
Hmmm....... you could also use:
"Where do you want to go today? Well, say about a year from now? You want
that, you might be talking three years from now, but where do you want to
go, then?"
--
MichKa
Michael Kaplan
Trigeminal Software, Inc.
http://www.trigeminal.com/
|
| Fri, 30 May 2003 02:02:53 GMT |
|
|
|
Richard Curzo
#15 / 15
|
Is this a bug... a big one? Victoria Not clear on what the problem is, but you are ahead of me in trying it out.
Am I wrong to think you can still do this:
- create an assembly (metadata) file that includes various EXE files, DLL
files in it's manifest.
- the files in the manifest can be produced by any dot-net language compiler
- but they have to be available/present when producing the manifest, unless
they are "shared"
- If not "shared", and you to update a component (say the COBOL EXE file),
you'd have to deliver to the user a new assembly file. This new assembly in
turn could force a download of the new component.
- if you want the ability to produce components that can be updated WITHOUT
updating the manifest, you can still do that by creating shared components
which have independent versioning
- one strategy for a product where you expect updates would be: create an
assembly file that is as empty as possible of anything but the manifest, not
sure how easy this would be yet. Then the manifest controls the rest of the
show.
Now is that smoke, or does it work?
Quote: > So now I am pissed. (American Pissed/Mad)
Getting Canadian/British pissed is the best cure for getting American pissed. <g>. regards
Richard.
|
| Fri, 30 May 2003 03:04:37 GMT |
|
| |
|
