Develop Reference

compilation using roslyn and modifications on the fly

I've seen a lot of people talk about the Roslyn compiler and its ability to compile as a service. There's a feature in Java when developing in Eclipse (not sure if it's only Eclipse) that allows you to modify the code without stopping or pausing the application. This is really useful when debugging render in games (that's what I use it for). Will the new abilities that Roslyn brings allow such a thing in .Net development?

Will the new abilities that Roslyn brings allow such a thing in .Net development?
No, Roslyn is still mostly a traditional compiler: code comes in and an assembly (.exe or .dll) comes out.
What's different with Roslyn is that it lets you manipulate code. But it doesn't do anything regarding manipulating assemblies, which I think would be required for what you're asking.

Because of dynamic compilation we can just make the changes in the code and need to just refresh the browser to reflect our changes.In the previous versions of ASP.NET we have to make code changes then re-build the solution and then refresh the browser for our changes to take effect.
Now we can just change make the code change and refresh the browser for our change to reflect.
http://www.codeproject.com/Articles/835251/Overview-of-ASP-NET-vNext

JSIL vs Script# vs SharpKit

I'm looking at Script#, JSIL and SharpKit as a tool to use to compile C# to Javascript, so I can program the client side functions of AJAX using C# in Visual Studio.
What are the pros and cons of each JSIL, Script# and SharpKit?
My project is a MVC4 project using razor engine and C#, if it matters.

If you're looking to integrate directly with an MVC project, something like Script# or SharpKit or something is probably your best bet - I know for a fact that Script# has stuff built in to make that sort of integration easier, so I would start there.
If you do want to try using JSIL, it probably has the core features you need, but things that you might want - like visual studio integration, automated deployment, etc - are not there. At present it is primarily targeted at cross-compilation of applications, so it does a good job of that but not as good a job of other use cases.
I'll try to give a summary of reasons why you might want to consider JSIL over those other alternatives - I can't really comment on the pros and cons of those alternatives in depth since I haven't used them:
JSIL has extremely wide support for the features available in C# 4. Notable ones (either because other tools don't support them, or they're complicated) include:
dynamic, yield, Structs, ref / out, Delegates, Generics, Nullables, Interfaces, and Enums.
Some of the above, of course, don't have complete support - to get an idea of things that absolutely will work, you can look at the test cases - each one is a small self-contained .cs file that is tested to ensure that JSIL and native C# produce the same output.
The reason for this extensive support is that my goal is for JSIL to enable you to translate a completely unmodified C# application to working JS. For all the demos up on the JSIL site, this is true, and I have a few nearly finished ports of larger real games in the wings for which this is also true.
Another reason is that JSIL makes it relatively straightforward for your C# and your JavaScript to talk.
All your C# types and methods are exposed via an interface that is as javascript-friendly as possible. The JS versions have basic overload resolution and dispatch so that native C# interfaces are callable from script code as if they were native JS in most cases. You don't have to take any steps to specifically tag methods you wish to expose to JS, or give them special names, or anything like that unless you want to.
When you want to call out from C# to JS, you can do it a few ways:
JSIL.Verbatim.Expression lets you insert raw javascript directly into the translated version of a function.
JSIL.Builtins.Global can be combined with dynamic and var to write JavaScript-like code directly in your C# function bodies.
The JSReplacement attribute can be used to replace invocations of a C# function with a parameterized JavaScript expression.
All of the above features can be combined with JSIL's mechanism for altering type information, called Proxies, to allow you to alter the type information of libraries you use, even if you don't have source code, in order to map their methods to JavaScript you've written.
And finally, C# methods that aren't translated to JS produce an empty method called an External that you can then replace with JavaScript at runtime to make it work again. Any External methods that you haven't replaced produce clear warning message at runtimes so you know what's missing.
JSIL makes aggressive use of type information, along with metadata you provide, to try and safely optimize the JavaScript it generates for you. In some cases this can produce better equivalent JavaScript than you would have written by hand - the main area where this is true at present is code that uses structs, but it also can apply in other cases.
For example, in this code snippet, JSIL is able to statically determine that despite the number of struct copies implied by the code, none of the copies are actually necessary for the code to behave correctly. The resulting JavaScript ends up not having any unnecessary copies, so it runs much faster than what you'd get if you naively translated the semantics of the original C#. This is a nice middle ground between writing the naive struct-based thing (Vector2s everywhere!) and going completely nuts with named return value optimization by hand, which, as I've described in the past, is pretty error-prone.
Okay, now for some downsides. Don't consider this list exhaustive:
Large portions of the .NET BCL don't have implementations provided for you by JSIL. In the future this may be addressed by translating the entire Mono mscorlib to JavaScript, but I don't have that working well enough to advocate it as an immediate solution. (This is fine for games so far, since they don't use much of the BCL.) This issue is primarily due to the IP problems related to translating Microsoft's mscorlib - if I could do that legally, I'd be doing it right now - it worked the last time I tested it.
As mentioned above, no visual studio integration. JSIL is pretty easy to use - you can feed it a .sln file to get a bunch of .js outputs automatically, and configure it automatically with a configuration file next to the project - but it's nowhere near as polished or integrated as say, Script#.
No vendor or support staff. If you want a bug fixed yesterday or you're having issues, I'm pretty much your only bet at present (though there are a few prolific contributors helping make things better, and more are always welcome!)
JavaScript performance is a goddamn labyrinth full of invisible land mines. If you just want apps to work, you probably won't have any issues here, but if like me you're trying to make real games run fast in browsers, JavaScript will make your life hell and in some cases JSIL will make it worse. The only good thing I can say here is that I'm working on it. :)
JavaScript minifiers and optimizers like Closure are explicitly not supported, because they require your code generator to jump through a bunch of hoops. I could see this being a real blocker depending on how you intend to use your code.
The static analyzer is still kind of fragile and there are still gaps in the language support. Each big application I port using JSIL usually reveals one or two bugs in JSIL - not huge game breakers, but ones that definitely break a feature or make things run slow.
Hope this information is helpful! Thanks for your interest.

Script# pros:
Free
Open source
Generates clean JavaScript
Script# cons:
Supports a subset of C# 2.0 language only
Can be compiled only in a separate project, cannot mix / re-use code between client and server
Low frequency of version updates
Does not offer support
Limited 3rd party library support, C# API is different than JavaScript API.
Not open source
Debugging in JavaScript only
SharpKit pros:
Commercial product
Supports full C# 4.0 language
High frequency of version updates
Support is available
Client / server code can be mixed and re-used within the same project
Extensive 3rd party library support, maintained as open-source - C# API matches exactly to JavaScript API
Supports basic C# debugging for Chrome browsers
Generates clean JavaScript
SharpKit cons:
Has a free version with no time limit, but limited to small / open-source projects
Not open source (only libraries are open-source)
JSIL pros:
Free
Open-source
JSIL cons:
Converts from IL (intermediate language), not from C#, which means a lower abstraction layer since code is already low-level.
Complex generated JavaScript code - almost like IL, hard to read and debug
Answers to feedbacks:
Kevin: JSIL output is not bad, it's simply generated to achieve full .NET behavior, much like SharpKit's CLR mode. On the other hand, SharpKit supports native code generation, in which any native JavaScript code can be generated from C#, exactly as it would have written by hand.
Sample of SharpKit's clean generated JavaScript code:
http://sharpkit.net/Wiki/Using_SharpKit.wiki
Developer can choose to create more complex code generation and gain more features, like support for compile-time method overloads. When specified, SharpKit generates method suffixes to overloaded methods.
Script# requires .NET 4 in order to run, but it does not support full C# 4.0 syntax, like Generics, ref and out parameters, namespace aliases, etc...

Another alternative is WootzJs. Full Disclosure, I am its author.
WootzJs is open-source and strives to be a fairly lightweight cross-compiler that allows for all the major C# language features.
Notable Language Features Supported:
yield statements (generated as an efficient state machine)
async/await methods (generated as a state machine like the C# compiler)
ref and out parameters
expression trees
lambdas and delegates (with proper capturing of this)
generics support in both the compiler and the runtime (invalidly casting to T will throw a cast exception)
C# semantics (as opposed to Javascript semantics) for closed varaibles
It is implemented using Roslyn, which means it will be first in line to take
advantage of future language improvements, since those will now be implemented via Roslyn itself. It provides a custom version of mscorlib so you know exactly what library functionality is actually available to you in your scripts.
What Are its Downsides?
The Javascript is not intended to look "pretty". It is clearly machine generated, though individual methods should be easy to reason about by looking at them.
Because of its extensive support for core libraries and reflection, the generated output is not the smallest on the block. Minification should produce an ~100k JS file, but minification is not yet supported.
WootzJs unabashedly pollutes native types with functions to encapsulate behavior for those types that would only be found in C#. For example, all the methods of System.String are added to the native Javascript String type.
Little support for binding to 3rd-party Javascript libraries presently exist. (Currently only jQuery)
Comparisons with Other Cross-Compilers:
Script# is very stable and has extensive integration with 3rd party Javascript libraries. Furthermore, it has excellent Visual Studio integration, and it provides a custom implementation of mscorlib. This means that you know precisely what functionality has actually been implemented at the tooling level. If, for example, Console.Write() is not implemented, that method will not be available in your editor.
However, due to its custom parser, it is still stuck in C# 2.0 (without even the generics found in that version of C#). This means that the modern C# developer is giving up an enormous set of language features that most of us depend on without reservation -- particularly the aforementioned generics in addition to lambdas and LINQ. This makes Script# essentially a non-starter for many developers.
JSIL is an extremely impressive work that cross-compiles IL into Javascript. It is so robust it can easily handle the cross-compilation of large 3d video games. The downside is that because of its completeness the resultant Javascript files are enormous. If you just want mscorlib.dll and System.dll, it's about a 50MB download. Furthermore, this project is really not designed to be used in the context of a web application, and the amount of effort required to get started is a bit daunting.
This toolkit too implements a custom mscorlib, again allowing you to know what capabilities are available to you. However, it has poor Visual Studio integration, forcing you to create all the custom build steps necessary to invoke the compiler and copy the output to the desired location.
SharpKit: this commercial product strives to provide support for most of the C# 4.0 language features. It generally
succeeds and there's a decent chance this product will meet your needs. It is lightweight (small .JS files), supports modern C# language features (generics, LINQ, etc.) and is usually reliable. It also has a large number of bindings for 3rd party Javascript librarires. However, there are a surprising number of edge cases that you will invariably encounter that are not supported.
For example, the type system is shallow and does not support representing generics or arrays (i.e. typeof(Foo[]) == typeof(Bar[]), typeof(List<string>) == typeof(List<int>)). The support for reflection is limited, with various member types incapable of supporting attributes. Expression tree support is non-existent, and the yield implementation is inefficient (no state machine). Also, a custom mscorlib is not available, and script C# files and normal C# files are intermingled in your projects, forcing you to decorate each and every script file with a [JsType] attribute to distinguish them from normally compiled classes.

We have SharpKit for two years and I must say that's upgraded the way we write code.
The pros as I see them:
The code is much more structured - we can now developed infrastrcture just like we did in C# without "banging our heads" with prototype.
It is very easy to refactor
We can use Code Snippets which results in better productivity and less development time
You can control the way the JS is rendered (you have several modes to choose from).
We can debug our C# code in the browser (Currently supported on Chrome only, but still :->)
Great support! If you send them a query you get a response very fast.
Support a large number of libraries & easily extensible
The cons:
The documentation is a bit poor, however once you get a hang of it you'll boost your development.

Glad if this could help!
For ScriptSharp, this stackoverflow link could be of help.
What advantages can ScriptSharp bring to my tool kit?
If you have any SVN tool, please download a sample from https://github.com/kevingadd/JSIL, this is a working source code and can help you go miles.

Bestpractice approaches for reverse engineering VB6 code with out knowledge of the domain

target state: Porting VB6 Code into C#, undertake the whole project with all conceivable processes that are involved.
What would be your approach if you do not have knowledge about the domain?
There is nearly any documentation, just legacy code (up to 100.000 - 300.000 lines of code and comments vb6 files that contain up to 14.000 lines of code) written in VB6.

Disclaimer: I work for Great Migrations
We rewrite large VB6/ASP/COM applications to .NET (primarily C#) for a living and we have developed a software analysis and reengineering tool to help us do it. This tool is essentially like a VB6/ASP/COM compiler and a decompiler that authors .NET codes. Of course since the VB6 platform is very different from .NET, a direct compile/decompile is not desirable or viable, so our tool has an "analyzer" that implements various code reengineering algorithms to deal with VB6-C# incompatibilities. There is also a programmable "author" that allows the migration team to prescribe rules for setting up .NET code files, restructuring the code, and doing things like replacing COM APIs and ActiveX controls with .NET classes -- depending on what the team needs or wants.
As a by product of compiling and analyzing the code our tool produces a model of the entire VB6/ASP/COM system being upgraded. This model can be used to produce extremely detailed reports about the internal structure of the system. These models can be used to help reverse-engineer the code -- if you know the right questions to ask and you would need to understand the problem domain to do a good job.
Of course once you have build-complete .NET, you can use the various analytics and code review tools that work off assemblies. Some versions of Visual Studio have these tools and there are open source tools such as FxCop, NDepends). There are also some fantastic dynamic analysis tools (EQUATEC Tracer) that I have used.
In the end though migration teams are going to very hard pressed to verify any unknown system. Even if you are staying on the same platform, you would unable to prove an application it is "correct" if you do not know how to run it and how to setup/enter expected inputs and find/verify expected outputs. We normally leave this to the customer!
If we are doing verification for the customer, we rely heavily on side-by-side testing to validate the new version of your system -- assuming we know how to run the legacy application we assume that given the same sets of inputs and usecases it should exhibit the same behaviors and produce the same results. I have heard this Approval Tests in unit testing circles.
I admit we also rely heavily on the knowledge that the VB6/COM code is a complete, detailed, formal and production tested description of the data structures and logic of the system and that we are putting this information through a tested and retested systematic transformation. We have been developing compilers since 1977 and we have worked very hard on this VB6/ASP compiler to make sure the .NET codes that we generate preserves the semantics of the original VB6. It is not 100% every time - but it is getting closer all the time. Then again doing things by hand does not guarantee 100% correct code on the first try either...

mark's answer about Great Migrations is excellent. Do be aware there are competitor automatic tools, which also have a very good reputation.
Artinsoft's VB Upgrade Companion
Francesco Balena's VB Migration Partner

2 basic but interesting questions about .NET

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.

Is it possible to load and execute C# snippets using DLR?

The majority of material I have found regarding DLR is related to IronPython. Can you parse and execute C# using DLR? If so is there over head that would prevent you from attempting this on a web server with about 30 users?
More specifically I would like to script the configuration of my workflow objects when a user first initiates a workflow. Depending on conditions that change through out the year workflows may start at different steps, hence running configuration scripts seems like a good way to handle the variation.

It sounds like you're really talking about the C# "compiler as a service" (at the end of this video), which will hopefully be in the 5.0 timescale for .NET (although Mono has it now). For now, CSharpCodeProvider is the best we have (which works largely like "csc").

Although Marc offered an alternative for me, I read this related SO question and C# and VB are not supported as of yet.

You may find this relevant...though it doesn't run on the DLR itself.
Mono Compiler as a Service (MCS)
It has the advantage of running snippets and not loading a new assembly on every compile like CodeDom does.