According to the C# spec 5.0 (sec 1.2)
The key organizational concepts in C# are 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. Classes and interfaces are examples of types. Fields, methods, properties, and events are examples of members. When C# programs are compiled, they are physically packaged into assemblies. Assemblies typically have the file extension .exe or .dll, depending on whether they implement applications or libraries.
But they never explain what a program is! Is a program the set of all source files that are used to create a single assembly? Or might a program be made up of several assemblies?
It matters because later the "program" is used to define other concepts, such as internal accessibility.
To Clarify: I'm asking, within the context of the C# 5.0 Specification, what is a "program"?
Either or. Based on the above definition, a program is a concept rather than a physically defined boundary. As such, it could be a single dll or a large collection of assemblies.
Basically, a program is a set of instructions that could be executed in a computer to perform a specific task. It could be a collection of assemblies or a single assembly to perform a task. It doesn't necessarily be a complete solution. I.e. it's not an application. Some may argue that they are same. But, there's a difference. They are not synonyms.
To understand what a program is you should understand the difference between a program and an application. There's a distinction between an application and a program.
A computer program, or just a program, is a sequence of instructions,
written to perform a specified task with a computer. - Wikipedia
On the other hand, an application is a set of programs working together to solve a complex problem.
Application software is a set of one or more programs designed to carry out operations for a specific application. - Wikipedia
E.g. To solve a specific business problem you might need an application, which internally performs multiple tasks to solve that problem.
John, I think the whole confusion is due to historical and terminological inconsistencies. In the beginning of computer era, only programs existed. Everybody understood a computer program as ANY SET OF INSTRUCTION for computer with defined functionality. It did not matter whether it was written on a paper, punched on punchcards, or recorded on a tape. Then new generations of software developers, languages, frameworks, etc. produced new terms, some of which had the same meaning, but carried different names. I can point to the similar story with "function" (C, C++) vs "method" (C#). In general, there is no point in answering to your question - it will not produce any practical results.
Thanks for the input. Apologies, if my question was unclear. I meant to ask: Within the context of the C# 5.0 Specification, what is a "program"? Rereading section 3.5.2 carefully, now I think it is clear that a "program" is intended to mean the set of source files that are used to create a single assembly (exe or dll). I do not think the specification is ambiguous. Throughout the entire specification "program" always has this definition. But it is unfortunately never actually defined. Probably it will be improved in C# 6.0.
Related
Following the idea of this question:
Is there a way to compare two .NET .dlls from the point of view of the CLI instructions and native instructions, to ensure that they are exactly the same, mean will behave exactly the same at runtime?
Typical use case is: you want to ensure that you have a reproducible build environment: that all developer machines compile exactly the same code as the build server.
The hash of the .dll file is not sufficient as the .NET compiler doesn't guarantee two identical .dlls are produced when compiling the same source code twice (and effectively changes a few bytes at the top and at the tail of the dll).
This question is similar to this former one, but the question didn't focus on the functional/behavior aspects of the .dlls, resulting in unclear answers and confused conversation.
One possible way could be to write unit tests. But not sure if it will also cover the statement:
from the point of view of the CLI instructions and native instructions
This question already has answers here:
Mixing C# & VB In The Same Project
(17 answers)
Closed 5 years ago.
I am working on an asp.net(c#) project for a client. He wanted to add one more team member and that person want to write code in VB.net. So is that possible that for that same project we have pages with different languages ??
It's possible, kind of. Instead of saying how though, I'm going to say why it's a terrible idea (usually):
The C# programmer will have to get warmed up to VB.Net when a bug is found there
The VB.Net programmer will have to get warmed up to C# when a bug is found there
Sure, you could maybe pretend that each programmer will "own" the code and will never have to deal with the other language... but then
You determine you need another programmer
So, in most cases DON'T DO THAT! Instead, choose one of the other. VB.Net is fine, C# is fine. But mixing them in the same project is stupid and just leads to confusion and frustration
Now, that being said, there are exceptions. Visual Studio doesn't allow for one of intermix languages in a single project, so this basically means you're forced to make the different language portion be a separate library. This is recognized as a shortcoming in Visual Studio, but really, for the reasons said above, this is why this isn't supported(probably).
So, If you're considering using two different languages, ensure the following:
They are separate enough for one to be a library
You'll actually gain some value from using another language (for instance, writing a very stateless and asynchronous library, would benefit from F#)
If #2 isn't satisfied, then ensure that programmers in one language should rarely need to touch the library in the other language. (hint: usually not the case)
It's not possible to combine files in different languages in a single project. You can, however, add a project in a different .NET language to your solution.
This may be appropriate if you are adding utility code which you intend to reference from your main project. However, doing it to extend the functionality of an existing application or web site is likely to cause you a lot of headache.
This is question is inspired by the question: In what areas does F# make "absolute no sense in using"?
In theory, it should be possible to use any .NET supported language in a single project. Since every thing should be compiled into IL code, then linked into a single assembly.
Some benefits would include the ability to use say F# for one class, where F# is more suited to implement it's function, and C# for another.
Is there some technical limitation I'm overlooking that prevents this sort of setup?
A project is restricted to a single language because, under the hood, a project is not much more than an MSBuild script which calls one of the command-line compilers to produce an assembly from the various source code files "contained" in the project folder. There is a different compiler for each language (CSC.exe is for example the one for C#), and what each project has to do to turn its "contained" source code into an assembly differs with each language.
To allow multiple languages to be compiled into a single assembly, the project would basically have to produce an assembly for each language, then IL-Merge them. This is costly, requires complex automation and project file code generation, and in most circumstances it's a pretty fringe need, so the VS team simply didn't build it in.
While projects are restricted to a single language, a solution is not... and solutions can contain multiple projects.
As others mentioned, a project is a stand-alone unit that is compiled by a single compiler.
I hear the question about including e.g. one F# type in a larger C# project quite often, so I'll add some details from the F# specific point of view. There are quite a few technical problems that would make it really difficult to mix F# and C# in one project:
C# compiler sees all classes, while F# type declarations are order-dependent. I'm not sure how would you even specify what types should the F# code see at which point.
F# compiler needs to know how declarations are used in order to infer types. Would it also get usage information from the C# compiler?
The two compilers use different representation of types. When compiling, there are no System.Type information, so how would they share the information? (Both of them would need to agree on some common interface that allows them to include language-specific information - and the information may be also incomplete).
I think this is enough to explain that doing this is not just a feature that may or may not be done depending on the schedule. It is actually an interesting research problem.
For what it's worth, it's possible to have ASP.NET projects that use C# and VB.NET (or anything else, you define the compilers in web.config), just in different files.
All code files are processed by a single compiler. That's why a project can only contain a single language.
Mixing languages may not make much sense either, since each language generates it's own IL.
This of course doesn't restrict you form having multiple projects from different langauges in the same solution, since each project is compiled independently
Consider using ILMerge if you want to maintain a single .exe or .dll built by a number of different compilers.
Technically, you can mix languages in a single project, if one (or more) of those languages are scripting languages. See How to use Microsoft.Scripting.Hosting? for more details.
I know this isn't what you were talking about, but it's a little fun fact if you weren't aware.
The project file is nothing but an elevated list of command line parameters to the relevant compiler. A file with the extension of .csproj contains the parameters for a C# compiler, .vbproj for the VB.NET compiler and so on.
You can however create two or more projects in the same solution file, one for each language and then link them together in one exe file using ILMerge.
I've gotten to the point where I have made a few classes that I have found to be rather useful for a variety of different projects, they're either extensions of the already existing .Net ones or something entirely new.
Although I may not use them for EVERY project I would most certainly use them again at some point, my questions is what is the best way to keep these stored?
I was thinking about compiling them into a .dll that I can simply reference if necessary but at the moment there are only about 4 different classes, I've always thought that a .dll is more suited towards a larger amount of classes.
Would it just be simpler to store them somewhere in the cloud so I can access them from pretty much any computer?
What has worked best for you?
Edit: I'll be using more than one computer as I sometimes use the university computer facilities.
The classes range from memory management helper classes in XNA to niche functions in regular .Net/C#
If the classes don't fit together naturally as an assembly, keep the source files somewhere like Github and include them in your projects where needed. You can always rearrange them into components at a later date, when you feel it's worthwhile.
Are these classes in any way related? If you want to use one of them, do you need the others? If not, then those don't belong in a common package together.
Robert C. Martin provides some decent introduction in the chapter "Principles of Package and Component Design" of his book "Agile Software Development". There is also a C# adapted version with very similar content called "Agile Principles, Patterns and Practices in C#".
What I'm just saying is, packaging components is not only about thinking components X and Y are "cool enough" to be reused, but also about how you organize things and how well libraries or packages fit into the big picture.
You could compile them as a DLL and install them to the GAC. Then you can reference the DLLs from any project you need, just like any native C# library.
And I agree with Jim Brissom. Compile only the classes that go together as one assembly.
I keep my common classes in sourcegear and then share them into any projects as required.
when I first saw C#, I thought this must be some joke. I was starting with programming in C. But in C# you could just drag and drop objects, and just write event code to them. It was so simple.
Now, I still like C the most, because I am very attracted to the basic low level operations, and C is just next level of assembler, with few basic routines, so I like it very much. Even more because I write little apps for micro-controllers.
But yesterday I wrote very simple control program for my micro-controller based LED cube in asm, and I needed some way to simply create animation sequences to the Cube. So, I remembered C#. I have practically NO C# skills, but still I created simple program to make animation sequences in about hour with GUI, just with help of google and help of the embedded function descriptions in C#.
So, to get to the point, is there some other reason then top speed, to use any other language than C#? I mean, it is so effective. I know that Java is a bit of similar, but I expect C# to be more Windows effective since its directly from Microsoft.
The second question is, what is the advantage of compiling into CIL, and than run by CLR, than directly compile it into machine code? I know that portability is one, but since C# is mainly for Windows, wouldn´t it be more powerful to just compile it directly? Thanks.
1 - diff languages have their pros and cons. There are families of languages (functional, dynamic, static, etc.) which are better for specific problem domains. You'd need to learn one in each family to know when to choose which one. e.g. to write a simple script, I'd pick Ruby over C#
2 - Compiling it to CIL: Portability may not be a big deal.. but to be precise Mono has an implementation of the CLR on Linux. So there. Also CIL helps you to mix-and-match across languages that run on the CLR. e.g. IronRuby can access standard framework libraries written in C#. It also enables the CLR to leverage the actual hardware (e.g. turn on optimizations, use specific instructions) on which the program is run. The CLR on 2 machines would produce the best native code from the same IL for the respective machine.
Language and platform choice are a function of project goal. It sounds like you enjoy system level programming, which is one of the strong points of using C/C++. So, keep writing systems level code if that's what you enjoy.
Writing in C# is strong in rapid business application development where the goals are inherently different. Writing good working code faster is worth money in both man-hours and time to market. Microsoft does us a huge favor with providing an expressive language and a solid framework of functionality that prevents us from having to write low level code or tooling for 95% of business needs.
One important advantage of IL is language independance. You can define modules in project which should be done in C++, some in C# and some in VB.net. All these projects when compiled give respective assemblies(.dll/.exe). This you can use the assembly for C++ project in the c# one and vice versa. This is possible because.. no matter which language (.net supported) you choose.. all compile to the same IL code.
I'm not sure that C# is more effective only because is a Microsoft product. If you use the Visual Studio, or other RAD, some of the code is auto-generated and sometimes is less efficient. Some years ago I was a dogmatic, thinking only C can response all our prayers :-P , but now I think virtual machines can help a lot in the way to optimize code before to execute it (like a RDBMS), storing in caché pieces of code to execute later, etc. Including the possibility to create "clusters" of virtual machines as Terracotta does. At least the benefits of having an extra abstraction layer are bigger that don't have it.
I agree with spoulson. C# is really good at solving business problems. You can very effective create a framework that models your business processes and solve many of those problems with object orientation and design patterns. In that respect it provides much of the nice object oriented capability that C++ has.
If you are concerned with speed, C is the route to go for the reasons that you stated.
Further on the second question: you can run NGEN to generate a native image of the assembly, which can improve performance. Not quite machine code, but since it bypasses the JIT (just-in-time compile) phase, the app will tend to run much faster.
http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx
The Native Image Generator (Ngen.exe)
is a tool that improves the
performance of managed applications.
Ngen.exe creates native images, which
are files containing compiled
processor-specific machine code, and
installs them into the native image
cache on the local computer. The
runtime can use native images from the
cache instead of using the
just-in-time (JIT) compiler to compile
the original assembly.
"is there some other reason then top
speed, to use any other language than
C#?"
I can think of at least four, all somewhat related:
I have a a large current investment in 'language X', and I don't have the time or money to switch to something else. (Port an existing code base, buy/acquire/port libraries, re-develop team skills in C#, learn different tools.)
An anticipated need to port the code to a platform where C# is not supported.
I need to use tools that are not available in C#, or are not as well supported. (IDE's, alternate compilers, code generators, libraries, the list goes on and on...)
I've found a language that's even more productive. ;-)
"what is the advantage of compiling
into CIL, and than run by CLR, than
directly compile it into machine
code?"
It's all about giving the runtime environment more control over the way the code executes. If you compile to machien code, a lot becomes 'set in stone' at that time. Deferring compilation to machine code until you know more about the runtime environment lets you optimize in ways you might not be able to otherwise. Just a few off the top of my head:
Deferring compilation lets you select instructions that more closely match your host CPU. (To use 64-bit native instructions when you have them, or the latest SSE extensions.)
Deferring code lets you optimize in ways you might not be able to otherwise. (If you have only one class at runtime that's derived from a specific interface, you can start to inline even virtual methods, etc.)
Garbage collectors sometimes need to insert checkpoints into user code. Deferring compilation lets the GC have more control and flexibility over how that's done.
First answer: C# should be used by default for new projects. There are a few cases where it hasn't caught up yet to C++ (in terms of multi-paradign support), but it is heading in that direction.
Second answer: "portability" also includes x86 / x64 portability, which can be achieved by setting the platform to AnyCPU. Another (more theoretical at this point) advantage is that the JIT compiler can take advantage of the CPU-specific instruction set and thus optimize more effectively.