C# runtime version

[marcus]

Hi,

I'm trying to get a C# application developed with .NET 2.0 tools to run
with .NET 1.1. runtime. Is this possible? I have only used methods and
properties compatible on .NET 1.1.

Are there specific build options that I need to use?

Are there samples on writing configure files that manage the runtime
version checks? Is it possible to append this configuration file to the
executable file instead of having it as a sidecar (side-by-side file)?
Is it possible to have the compiler automatically generate the
configuration file depending on the C# sources?

Thanks for any help
Regards
Marcus

P.S. I'm new to C# D.S.

 

[Nicholas Paldino [.NET/C# MVP]]

marcus,

From what I hear, you can do it, but at the same time, I don't think it
is a good idea. It would be unsupported, and a good number of the tools
would no longer work, since they rely on new classes in the framework, which
don't exist for .NET 1.1.

If you search the google for this group, there are a few posts on the
topic, with links to resources on how to do it.

Hope this helps.

 

[marcus]

You mean that it is a bad idea to append this info into the executable
file?

Thanks,
Marcus

 

[Jon Skeet [C# MVP]]

I'm trying to get a C# application developed with .NET 2.0 tools to run
with .NET 1.1. runtime. Is this possible? I have only used methods and
properties compatible on .NET 1.1.

There are currently a few tools which were geared towards the release
candidate of Visual Studio 2005. MS is coming up with an unsupported
tool to let you do this "properly" though:
http://blogs.msdn.com/clichten/archive/2005/11/08/490541.aspx

I'm surprised that MS didn't realise quite how big an issue this was
going to be a long time ago though - especially as they're trying to
compete with Java, where most IDEs have supported multiple runtime
versions for *ages*.

 

[Mattias Sjögren]

I'm trying to get a C# application developed with .NET 2.0 tools to run

with .NET 1.1. runtime. Is this possible?
No.


I have only used methods and properties compatible on .NET 1.1.

Still there are cahnegs to the metadata schema that causes the
assembly to fail to load on v1.x.


Mattias

 

[Nicholas Paldino [.NET/C# MVP]]

marcus,

Well, yes. You say you use tools that are available only in .NET 1.1.
I don't understand why you use the dev environment for 2.0, especially a
tool that generates so much code for you.

Basically, I would take the code and try to compile it in the 1.1 ide.
If it works, great, but all in all, I think the amount of checking you would
have to do in order to get code developed in the 2.0 IDE to compile in 1.1
is excessive.

 

[Jon Skeet [C# MVP]]

Well, yes. You say you use tools that are available only in .NET 1.1.
I don't understand why you use the dev environment for 2.0, especially a
tool that generates so much code for you.

I don't see that that's too hard to answer in a general case:

1) Visual Studio 2005 is a better environment in general
2) Visual Studio Team System provides many features which are
unavailable in VS.NET 2003 - why should I have to go without those
features just because I'm working on pre-2.0 code?
3) It seems unreasonable to have to have two different IDEs installed,
just to target two different runtimes with the same language.
4) There are times it's useful to be able to produce two different
outputs from the same source code - one for 1.1 and one for 2.0. Using
a different project configuration from the same IDE is much more
convenient than having to change IDEs.

A lot of people will have to do maintenance on code which is pre-2.0
for some time to come. I don't see why they should have to work with
old tools, when various other development platforms (eg Java IDEs) have
coped with this problem for a long time.

Basically, I would take the code and try to compile it in the 1.1 ide.
If it works, great, but all in all, I think the amount of checking you would
have to do in order to get code developed in the 2.0 IDE to compile in 1.1
is excessive.

Fortunately MS disagrees, hence the tool it's building

(It's really just a case of getting the project file correct for
MSBuild, I believe.)

Getting the IDE to load designers etc is a different matter, but at
that level I think it's reasonable to fail. Being able to just edit the
code manually is quite important though.

 

[Nicholas Paldino [.NET/C# MVP]]

See inline:

1) Visual Studio 2005 is a better environment in general
Agreed.

2) Visual Studio Team System provides many features which are
unavailable in VS.NET 2003 - why should I have to go without those
features just because I'm working on pre-2.0 code?

Because there are a good number of those features which are dependent on
new classes in the .NET 2.0 distribution. Take data binding, for example.
The BindingSource class does not exist in .NET 1.1.

Things like refactoring, however, I can understand. It depends on what
specific things the OP is looking to take advantage of.

3) It seems unreasonable to have to have two different IDEs installed,
just to target two different runtimes with the same language.

When dealing with minor revisions, I agree, but with the changes from
1.1 to 2.0, I think that the expectation of backwards compatability is just
outrageous.

4) There are times it's useful to be able to produce two different
outputs from the same source code - one for 1.1 and one for 2.0. Using
a different project configuration from the same IDE is much more
convenient than having to change IDEs.

I'll give you that, it's convenient, yes, but not horribly inefficient,
especially with the price of processors, memory, and disk space nowadays.
That's not to say that this is an excuse, but because of these factors,
having to switch between two environments isn't a nightmare scenario.

A lot of people will have to do maintenance on code which is pre-2.0
for some time to come. I don't see why they should have to work with
old tools, when various other development platforms (eg Java IDEs) have
coped with this problem for a long time.

Java has a little bit of an advantage in this little niche area.
Because they have been so reluctant to actually change the underlying
runtime drastically (unlike the change to the runtime from 1.1 to 2.0), they
get huge advantages in terms of maintaining backwards compatability with
previous frameworks.

Fortunately MS disagrees, hence the tool it's building

I disagree with that. If they truly agreed, it would have been in the
product to begin with. We both know that if they thought that it was
important enough, it would have been in there, but they didn't see it as
such. The fact that they are doing it now is because they are bowing to
customer demand, not because they actually think that it is viable enough.
Of course, that doesn't mean they are right, but it doesn't mean that they
agree with it.

 

[Jon Skeet [C# MVP]]

See inline:


Because there are a good number of those features which are dependent on
new classes in the .NET 2.0 distribution. Take data binding, for example.
The BindingSource class does not exist in .NET 1.1.

Things like refactoring, however, I can understand. It depends on what
specific things the OP is looking to take advantage of.

Indeed - and I would guess that as the OP has said he's not using any
2.0 features, that's not an issue. It's certainly not an issue for
*me*, and I want to be able to do this too

When dealing with minor revisions, I agree, but with the changes from
1.1 to 2.0, I think that the expectation of backwards compatability is just
outrageous.

All I want is for the IDE to be able to target a compiler for one
runtime while working with another. I don't even mind if it lets me
type in 2.0 syntax and then only complain when it's building.

I'll give you that, it's convenient, yes, but not horribly inefficient,
especially with the price of processors, memory, and disk space nowadays.
That's not to say that this is an excuse, but because of these factors,
having to switch between two environments isn't a nightmare scenario.

No, but it's pretty inconvenient.

Java has a little bit of an advantage in this little niche area.
Because they have been so reluctant to actually change the underlying
runtime drastically (unlike the change to the runtime from 1.1 to 2.0), they
get huge advantages in terms of maintaining backwards compatability with
previous frameworks.

Well, you still need to build different versions of bytecode, and
target different runtime libraries. Leaving designers etc aside, I
don't see that it's *that* different.

I disagree with that. If they truly agreed, it would have been in the
product to begin with. We both know that if they thought that it was
important enough, it would have been in there, but they didn't see it as
such. The fact that they are doing it now is because they are bowing to
customer demand, not because they actually think that it is viable enough.
Of course, that doesn't mean they are right, but it doesn't mean that they
agree with it.

Actually, they *wanted* it to begin with, according to a softie website
I was reading. They tried it and found it hard. I suspect they then
underestimated just how much demand there is for it (supposedly it's
one of the most requested features), and made the decision to cut it as
a feature based on that underestimate.

They're also trying to make it easier for the future, by the sounds of
it. I wish I could find the page which spoke about this. I was looking
at it just the other day...

 

[Olaf Baeyens]

I'm trying to get a C# application developed with .NET 2.0 tools to run

with .NET 1.1. runtime. Is this possible? I have only used methods and
properties compatible on .NET 1.1.

Are there specific build options that I need to use?

Is there any reason why you prefer v1.1 instead of v2.0?
You would think that v2.0 is far more superior compared to v1.1?

 

[marcus]

I selected my code to support compiling with 1.1 version, which I
thought I could do with some options for csc.exe or .config file, but
apparently not. Where can I get developer tools that compiles 1.1?

Regarding the embedded metadata / typelib symbols, can't I just strip
it away? Doesn't it just take up space and making my binaries larger
than they need to? For example, with C/C++ object code, I usually strip
debug symbols in release binaries.

Thanks for all help folks!
Regards
Marcus

 

[Olaf Baeyens]

Regarding the embedded metadata / typelib symbols, can't I just strip

it away? Doesn't it just take up space and making my binaries larger
than they need to? For example, with C/C++ object code, I usually strip
debug symbols in release binaries.

I am afraid that you need those in order to run.
This is the advantage of .NET dll's, it contains self documenting code, no
need to rely on header files to give you the correct calling parameters and
functions. And in modern days, I don't know if saving a few bytes is worth
the effort.

 

[Jon Skeet [C# MVP]]

I selected my code to support compiling with 1.1 version, which I
thought I could do with some options for csc.exe or .config file, but
apparently not. Where can I get developer tools that compiles 1.1?

Download and install the .NET 1.1 SDK. (Or even just the framework -
that comes with the C# compiler.)

Regarding the embedded metadata / typelib symbols, can't I just strip
it away? Doesn't it just take up space and making my binaries larger
than they need to? For example, with C/C++ object code, I usually strip
debug symbols in release binaries.

No, the metadata is very important in .NET.

Jon

 

[Willy Denoyette [MVP]]

I selected my code to support compiling with 1.1 version, which I
thought I could do with some options for csc.exe or .config file, but
apparently not. Where can I get developer tools that compiles 1.1?

Regarding the embedded metadata / typelib symbols, can't I just strip
it away? Doesn't it just take up space and making my binaries larger
than they need to? For example, with C/C++ object code, I usually strip
debug symbols in release binaries.

Debug symbols have nothing to do with metadata, you can't strip the
metadata, it's absolutely required by the run-time as it contains rich
runtime type info. Also the assemblies do not contain object code, they
contain IL (bytecode) which is more compact than object code, so what you
loose because of the metadata, is largely compensated by the smaller IL.

Willy.

 

[Jon Skeet [C# MVP]]

Is there any reason why you prefer v1.1 instead of v2.0?
You would think that v2.0 is far more superior compared to v1.1?

I don't know about the OP, but there's such a thing as maintenance. If
you're working on the maintenance cycle for a product, you really don't
want to start changing runtime versions...

Even if you're upgrading to a genuinely new version of your product,
you'd need to do a lot of extra testing to make sure everything still
works on 2.0.

Jon

 

[Olaf Baeyens]

Is there any reason why you prefer v1.1 instead of v2.0?

I don't know about the OP, but there's such a thing as maintenance. If
you're working on the maintenance cycle for a product, you really don't
want to start changing runtime versions...

Even if you're upgrading to a genuinely new version of your product,
you'd need to do a lot of extra testing to make sure everything still
works on 2.0.

But using the VS 2005 to create v1.1 .NET code will probably introduce more
problems than if you upgrade to v2.0.
If you need maintenance of a v1.1 framework, then you should stick to the VS
2003.

 

[Jon Skeet [C# MVP]]

But using the VS 2005 to create v1.1 .NET code will probably introduce more
problems than if you upgrade to v2.0.

I doubt it very much. You can end up compiling it with the same
compiler as you would use under VS.NET 2003, and you don't have to
worry about the changes in the runtime.

If you need maintenance of a v1.1 framework, then you should stick to the VS
2003.

I'm afraid I just don't accept that.

 

[marcus]

But using the VS 2005 to create v1.1 .NET code will probably introduce more
problems than if you upgrade to v2.0.
If you need maintenance of a v1.1 framework, then you should stick to the VS
2003.

Yes, I noticed that the language differences between C# 1.1 and 2.0 is
like comparing C with C++. Perhaps I exaggregated little now. (-:

Anyway, I didn't realize there were such major changes in the C#
language before I tried...

For example, when I compile 2.0-sources with csc 1.1, it wont
understand partial classes in different files.

Regards,
Marcus