Newbie Question On .Net Framework

[koorb]

Is the .Net framework a bit like java where my code talks to the
framework and then the framework takes to the OS?

And does this mean that my code will be Longhorn compatible with no
changes?

 

[J. Alan Rueckgauer]

Is the .Net framework a bit like java where my code talks to the
framework and then the framework takes to the OS?

Essentially, yes. However, there are numerous differences in the actual
strategies and implementation details that you should read about over on
MSDN. One of the "nicest" features of .Net is the out-of-the-box ability to
cleanly mix-and-match components created using different .Net languages.
Java pretty much keeps you locked into its environment by making you jump
through hoops if you want to use non-Java components as part of a solution.

And does this mean that my code will be Longhorn compatible with no
changes?

That's hard to say this far out. As long as you adhere to the rules and
recommended best practices, you should expect your app to transition without
much difficulty, but you cannot expect that you won't have to get under the
hood to tweak things.

A good rule of thumb is that anytime the underlying OS changes, you must
test against it to look for subtle or substantial compatibility issues. For
example, the upcoming XP SP2 does present a number of compatibility
challenges, some due to rewrites of the underlying code that require some
things be changed to conform to new rules, some due to some defaults being
changed and altering the assumptions your software can make about its
environment without user intervention.

Alan

 

[koorb]

Essentially, yes. However, there are numerous differences in the actual
strategies and implementation details that you should read about over on
MSDN. One of the "nicest" features of .Net is the out-of-the-box ability to
cleanly mix-and-match components created using different .Net languages.
Java pretty much keeps you locked into its environment by making you jump
through hoops if you want to use non-Java components as part of a solution.


That's hard to say this far out. As long as you adhere to the rules and
recommended best practices, you should expect your app to transition without
much difficulty, but you cannot expect that you won't have to get under the
hood to tweak things.

A good rule of thumb is that anytime the underlying OS changes, you must
test against it to look for subtle or substantial compatibility issues. For
example, the upcoming XP SP2 does present a number of compatibility
challenges, some due to rewrites of the underlying code that require some
things be changed to conform to new rules, some due to some defaults being
changed and altering the assumptions your software can make about its
environment without user intervention.

Alan

Thanks a lot, I did try looking this stuff up on MSDN, but the best I
could get was some corporate filing.

 

[Anon-E-Moose]

One of the "nicest" features of .Net is the out-of-the-box ability to
cleanly mix-and-match components created using different .Net
languages. Java pretty much keeps you locked into its environment by
making you jump through hoops if you want to use non-Java components
as part of a solution.

You're sort of comparing apples to oranges.

On one hand you're saying:

"cleanly mix-and-match components created using different .Net languages"

on the other:

"making you jump through hoops if you want to use non-Java components as
part of a solution."

Java is Java - so of course you can't expect it to support non-java
components.

 

[J. Alan Rueckgauer]

Try
http://msdn.microsoft.com/netframework/technologyinfo/news/articles/default.aspx
for some of the Java comparisons.

 

[koorb]

You're sort of comparing apples to oranges.

On one hand you're saying:

"cleanly mix-and-match components created using different .Net languages"

on the other:

"making you jump through hoops if you want to use non-Java components as
part of a solution."

Java is Java - so of course you can't expect it to support non-java
components.

I thought that was obvious.

 

[Anon-E-Moose]

I thought that was obvious.

Yes, .NET can't use non .NET components easily either - such as Java or
Delphi components.

 

[J. Alan Rueckgauer]

The point is that with .Net you can easily incorporate components whether
they were created with .Net or not, including Java, whereas Java isn't
nearly as accommodating.

Alan

 

[J. Alan Rueckgauer]

That isn't true for the vast majority of cases. As long as a COM component
adheres to the rules for properly defining its interface and conveying that
through IUnknown, .Net's RCWs and/or tlbimp makes working with them
painless.

Issues with Java interop come from inconsistencies in how SOAP defs of
complex native objects on the server are generated for mapping by WSDL, or
interpreting WSDL defs from .Net web services. This is an inherent issue
where vendors of Java products make it less than convenient to interop
without additional resources, regardless of whether it's another Java
vendor's products or Microsoft. However, most serious Java sites already
have the tools, like WSTK, for coping with this so it's usually more an
issue of just corralling some coders to make Java play nice.