Quote: 2: What are the keys to software components in C#?
- Programs, namespaces, types, members and assemblies.
- - "C# programs consist of one or more source files. Programs declare types, which contain members and can be organized into namespaces. When C# programs are compiled, they are physically packaged into assemblies."

Actually, the keys to software components in C# is that they present a programming model with properties, methods, and events; they have attributes that provide declarative information about the component; and they incorporate their own documentation

Quote: 11: What's the name of the C# Runtime libraries?
- .NET

The .NET Framework Library, to be more specific. =) '.NET' is really the combination of both the CLR, as well as the Framework Libraries. But it's important to note that C#'s core libraries is the .NET Framework Library itself.

Quote: 48: What is method overloading?
- This is when one or more methods have the same name but are distinguished by the arguments and return type.

Actually, this is not quite true. Method overloading permits multiple methods in the same class to have the same name, so long as they have unique signatures. A method's signature does not include its return type. As such, the return type isnt included when determining whether there are valid methods.

Cheers!

Quote: The IL instructions get converted to processor specific code by the JIT compiler. Is this code saved so it doesn't have to keep getting recompiled, and is it possible to pre-compile the code so the JIT doesn't have to when it is run? If so, what are the pros/cons of letting the JIT compile it at runtime?

It is possible to precompile an assembly using the ngen.exe tool. This tool does the JIT process and then saves the result as a native executable, so that the JIT step is skipped when the application is run. This provides greater speed for the application. There aren't really any problems using this method, but you do have to run ngen on the client's machine, because it takes into account the processor and other hardware details when creating the native image.

Quote: I have a question when answering question 1. Is it correct to say that object-oriented programming is a type of component-oriented programming? It seems to me that OOP is a type of COP because OOP helps you create "self-contained and self-describing packages of functionality".

Quote: It seems to me it's just a lot of fancy talk for "we facilitated OOP a little more" but decided to give it a different name. Someone tell me why I'm wrong?

You're wrong. [lol] OOP is, however, an essential ingrediant in Component Oriented Programming. Object Oriented Programming is a paradigm where features of a language such as methods and members can be combined into logical units. These logical units can then be re-used elsewhere within the program, or compiled into a library and used from many programs. Ultimately, however, the focus of OOP is on creating "objects."

Component-oriented Programming, on the other hand, focuses on the creation of re-usable "components", which can be used from a variety of languages. For informational purposes, "COM" the Component Object Model was Microsoft's first real attempt at CoP.

In order for software developers to create "components" which can easily be packaged and distributed for use in many different languages, it must be self-describing (this is where the meta-data of C# is essential) and it must support strong versioning. We'll talk more about this when we cover attributes, etc...but the key thing to note is that CoP focuses on creating re-usable components, which can be consumed by any application, where OOP focuses on creating reusable objects, which are primarily used within the same application, or within applications using a library of the same programming langauge.

Think of Component Oriented Programming as "Enterprise" OOP. [lol]

Cheers!

Quote: Original post by Mike.Popoloski

Quote: The IL instructions get converted to processor specific code by the JIT compiler. Is this code saved so it doesn't have to keep getting recompiled, and is it possible to pre-compile the code so the JIT doesn't have to when it is run? If so, what are the pros/cons of letting the JIT compile it at runtime?

It is possible to precompile an assembly using the ngen.exe tool. This tool does the JIT process and then saves the result as a native executable, so that the JIT step is skipped when the application is run. This provides greater speed for the application. There aren't really any problems using this method, but you do have to run ngen on the client's machine, because it takes into account the processor and other hardware details when creating the native image.

Allow me to disagree just a little bit. .NET applications are programs which run via the CLR, and which use the .NET Framework Library. By running ngen on an assembly, native machine code is generated for the assembly based upon the current .NET Framework Library, the current CPU, and the current Operating system of the person running ngen.exe.

This means that any patches, updates, or upgrades to the .NET Framework Library or the CLR will have no effect on the native image. This isn't a huge problem as one would hope the .NET version was stable to begin with, but it does make it more difficult for end-users to benefit from improvements to the framework itself.

Also, ngen compiles machine code based on the CPU and OS. So switches from Intel to AMD, or vice versa, could have negative impacts on performance, as the machine code created may have been taking advantage of unique speed improvements. Does this mean the image wont run on competing processors? No, it probably doesn't mean that, so long as the architecture is the same. However, again, there may be performance implications. And the above is true for the operating system as well. Switching from XP to Vista may have side effects upon performance, as the native image may have been generated with a different OS's libraries.

And finally, the CLR does things for the user beyond just generating JIT code. It does things such as perform security checks, etc...So by compiling it into native code you lose those benefits. And worse, if your native image was generated with certain required security permissions, there's no way to change that later. Whereas normally, the CLR could request different security permissions, etc...and the user could grant or deny as necessary.

Ok, one last thing. As Intermediate Language isn't machine specific, code written for the .NET CLR is highly portable. Like Java, any machine which runs a CLR could run the application. Although there are not many commercial CLR's available, there are a number of OpenSource projects currently creating CLR implementations on Linux, Mac, etc...This means that in the near future, code written for the CLR will easily run on multiple Operating Systems.

By running ngen, you lose that, as your code goes from highly portable, to barely portable.

Cheers!

Quote: Original post by JWalsh

Quote: Original post by Mike.Popoloski

Quote: The IL instructions get converted to processor specific code by the JIT compiler. Is this code saved so it doesn't have to keep getting recompiled, and is it possible to pre-compile the code so the JIT doesn't have to when it is run? If so, what are the pros/cons of letting the JIT compile it at runtime?

It is possible to precompile an assembly using the ngen.exe tool. This tool does the JIT process and then saves the result as a native executable, so that the JIT step is skipped when the application is run. This provides greater speed for the application. There aren't really any problems using this method, but you do have to run ngen on the client's machine, because it takes into account the processor and other hardware details when creating the native image.

Allow me to disagree just a little bit. .NET applications are programs which run via the CLR, and which use the .NET Framework Library. By running ngen on an assembly, native machine code is generated for the assembly based upon the current .NET Framework Library, the current CPU, and the current Operating system of the person running ngen.exe.

This means that any patches, updates, or upgrades to the .NET Framework Library or the CLR will have no effect on the native image. This isn't a huge problem as one would hope the .NET version was stable to begin with, but it does make it more difficult for end-users to benefit from improvements to the framework itself.

Also, ngen compiles machine code based on the CPU and OS. So switches from Intel to AMD, or vice versa, could have negative impacts on performance, as the machine code created may have been taking advantage of unique speed improvements. Does this mean the image wont run on competing processors? No, it probably doesn't mean that, so long as the architecture is the same. However, again, there may be performance implications. And the above is true for the operating system as well. Switching from XP to Vista may have side effects upon performance, as the native image may have been generated with a different OS's libraries.

I thought runtime discarded the compiled native image and resorted to JIT if the execution environment changed in these ways.

Quote: I thought runtime discarded the compiled native image and resorted to JIT if the execution environment changed in these ways.

Indeed, you are correct. Whenever you run an Intermediate Language (IL) .NET application, the CLR first attempts to locate a native image in the global assembly cache for that assembly. (thus, avoiding the overhead of JIT compiling)

However, any of the above mentioned changes causes the CLR to "invalidate" the native imagine as a possible alternative to the non-native assembly. This prevents the native imagine from being run, and the JIT compilation must be performed as usual.

My comments above were under the assumption that a person simply tried to execute a native imagine directly. Such as in the case of a developer distributing a natively compiled application. In this case, I believe it will run anyways, though Washu or someone with more CLR experience may be able to clarify.

In this event, would the native image be executed anyways...or do native images carry the IL code with them to be JIT compiled in the event the native image gets invalidated?

Cheers!

Quote: Original post by JWalsh

Quote: I thought runtime discarded the compiled native image and resorted to JIT if the execution environment changed in these ways.

Indeed, you are correct. Whenever you run an Intermediate Language (IL) .NET application, the CLR first attempts to locate a native image in the global assembly cache for that assembly. (thus, avoiding the overhead of JIT compiling)

However, any of the above mentioned changes causes the CLR to "invalidate" the native imagine as a possible alternative to the non-native assembly. This prevents the native imagine from being run, and the JIT compilation must be performed as usual.

My comments above were under the assumption that a person simply tried to execute a native imagine directly. Such as in the case of a developer distributing a natively compiled application. In this case, I believe it will run anyways, though Washu or someone with more CLR experience may be able to clarify.

In this event, would the native image be executed anyways...or do native images carry the IL code with them to be JIT compiled in the event the native image gets invalidated?

Cheers!

It does not store the original MSIL code within the native image. If the original assembly is not accessible then the application will no doubt just fail to run.

The assemblies will need to be explicitly rebuilt using ngen in the new execution environment.

The .NET framework will not rebuild the native images for you when updating to a new version, although it does rebuild its own native images automatically.

For .Net 2.0, native images generated are located in (for my particular install):

C:/Windows/assembly/NativeImages_v2.0.50727_32/<ProgramName>/<Scenario>/<ProgramName>.ni.exe

Where Scenario is either a GUID or a MD5 hash which somehow relates to the current machine configuration.

(Note - this path is only accessable from a command prompt. The C:/windows/assembly folder is a special folder when browsed in Explorer)

Also, it seems that the <ProgramName>.ni.exe is not a standalone runnable EXE file. I get the "<path name> is not a valid Win32 application" if I attempt to run it. You will not be able to redistribute the native image exe even if you wanted to.

Hey, no questions yet, but I was wondering if you were going to post the fist project, because you said in the introduction thread that you would post it at the very beginning of the workshop so we could fill in the gaps as we moved along. Thanks.

Any people here who are learning this as their first programming language?

I'm wondering how difficult is this for you? I've learned most of C++ before this and I find it somewhat challenging to keep up with all the keywords. I imagine for a new person all the new vocabulary must be overwhelming...

I know for me, these 2 chapters would scare the **** out of me =X

EDIT: Sorry, I'm not trying to discourage anyone, these 2 chapters must be the hardest - they're throwing everything at you at once. So if you get through these the rest should be much easier.