I'm used to being able to compile source code even if it has errors due to my Java (Eclipse) background. This is a tremendous help when developing test-first, which has become my modus operandi. Also it helps a lot with refactoring.
Is there any way to achieve something similar in C#? I have to use JetBrain's Rider, but I don't care much for the IDE.
The source code could not compiled when you violate the rules of writing syntax are known as Compile-Time errors.
Even in Java the source code could not compiled when incorrect syntax such as a missing semicolon at the end of a statement or a missing bracket, etc.
Related
Been looking for online sources (especially MS documentations) that clearly say when a compile-time error is generated. Sadly I have not found any. I do know that a compile-time error is generated because of incorrect syntax or incorrect semantics in C# code.
Is a compile-time error generated during program development (as I am writing C# code) or is a compile-time error at compile time (when the C# program is being compiled)?
Please include any credible C# MS documentation if possible. Perhaps there is one I have not yet read.
You’re asking the wrong question,
What does it mean when they are generated? obviously when you write something that can’t compile..
Compile time errors are errors that interferes compilation, it’s another question to ask, when those errors can be detected, obviously they will fail compilation, but can be detected prior to compilation. Almost every IDE today can recognize compile time errors before compilation.
I have decompiled C# dll and now can not compile it. It shows strange errors, for example in some switch blocks some case blocks havent their break statements, or errors like "Can not cast int to bool" are shown. But the amount of errors is not very large for dll of that size, so I think it is not the problem of decompiler.
Is there some derective for compiler (for example, smthing life unsafe) that will solve this problem? Or why is there such strange errors?
P.S. The dll is not broken - the application is using it right now. I'm using dotPeek to decompile and Visual Studio 15 to compile the result code.
For such an error like :
"Can not cast int to bool"
There is absolutely no compiler directive that will allow your compiler to go ahead, I think that your decompiler messed up something decompiling ... You could simply try with another decompiler and see if you get another results, valid alternatives are : ILSpy, JustDecompile and Dotnet IL Editor .
Be aware that some commercial DLL is obfuscated just to try to make life difficult to the decompiler and to who decompile ...
Be careful to avoid breaking some copyright .
It's quite hard to decompile IL to C# and decompiler has probably done something wrong. In my experience, decompiled and compiled code can also behave differently than original assembly, so be aware. And such compile error can be indocation that dotPeek was not sure, so think about it what it should do or look in IL.
If you are willing to make really small edits to the assembly (inject method calls, make something public) it may be safer to do it directly in IL obtained by ildasm.
I have an application and I will have two versions - Trial and Commercial. The trial will have some limited features compared to the Commercial version.However I need to make it so that when one has the trial version, it will be impossible for him to uncover the features in the full version. The simplest idea is to have two absolutely separate builds, however this will be hard to maintain(I think). The second idea I have is to build the solutions with a Conditional Compilation Symbols - Trial and Full. I will adapt the source to work this way and I will use #If statements. My question is if this is safe. As it seems the code which is not in the Full compilation symbol's #If statement will be excluded from the assembly but I need your help on this as I need to be sure. Thanks a lot
You are correct code excluded via conditional compilation will not be included in the resulting executable. In that way it is 'safe', i.e. it can't be hacked to execute code that isn't there. All managed code by it's nature is decompilable.
You cannot use conditional compilation to produce a single executable file that contains both states (defined/undefined) of your code and select behavior at runtime.
I have a domain specific language that I would like to interact with C# by adding new keywords (or some keyword-like syntax). Using attributes would be insufficient (I can't use them in method bodies), and shoehorning it into 'valid' C# notation that gets compiled into something else would be ugly and ruin the analogy with the DSL (and the translation from DSL-like notation to C# is nontrivial, so just writing the C# each time is out of the question).
I already have a way to parse the .cs file and transform it into legitimate, nontrivial, C# code which can be compiled.
The problem is, even through I can do all the work of defining the DSL, parsing it, and translating it into valid C#, Visual Studio won't let me use notation it doesn't understand; it just adds red squiggles, emits an error "cannot resolve symbol", and then often fails to properly parse things after it.
Is there a way to to force visual studio to ignore specific strings in its analysis? I've looked at visual studio plugins but it looks like, although I can do syntax highlighting and other stuff, I can't force it to ignore something it doesn't know how to parse (unless I'm missing some way to do that in the extension API, which is certainly possible).
I've skimmed through the Roslyn stuff and don't see offhand a way to do this there, either. (Again, may be missing something, it doesn't seem to have great documentation.)
Take a look at PowerLanguages.E: http://visualstudiogallery.msdn.microsoft.com/a512e0d0-f4f3-4435-bad4-8d5efbb1db4a
No english docs yet, sorry
So Jeff Atwood rightly complained about Visual Studio not performing background compilation see: http://www.codinghorror.com/blog/2007/05/c-and-the-compilation-tax.html
The solution from most sources seems to be Reshaper which will incrementally perform background compilation as you write. This leads to their great realtime re-factoring tips and error detection.
But what I don't understand is with R# continually compiling my code, why does it take so long when executing a compilation via VS (i.e. Ctrl + Shift + B or similar). What I mean by this is, if R# has already compiled my code then why would I need a recompilation?
My assumption is of course that R# is not overriding the assemblies in my bin directories but instead holding the compilation results in memory. In which case, is it possible to tell R# to simply override my assemblies when compilation is successful?
I don't know about "rightly complained" - that's an opinion I happen to disagree with:)
However, the VB.NET (and probably Resharper c#) background compilers do not actually compile full assemblies - they cannot! If you think about it, the natural state of your code while you are working is not compilable! Almost every keystroke puts your code in an invalid state. Think of this line:
var x = new Something();
As you type this, from the key "v" to the key ")", your code is "wrong". Or what if you are referencing a method you haven't defined yet? And if this code is in an assembly that another assembly requires, how would you compile that second assembly at all, background or not?
The background compilers get around this by compiling small chunks of your code into multiple transient "assemblies" that are actually just metadata holders - really, they don't care about the actual effects of the code as much as the symbols defined, used, etc. When you finally hit build, the actual full assemblies still need to be built.
So no, I don't believe it's possible because they're not built to do actual full compilation - they are built to check your code and interpret symbols on the fly.
Reshaper which will incrementally perform background compilation as you write
It doesn't, it just parses the source code. The exact same thing Visual Studio already does if you don't have Resharper, that's how it implements IntelliSense, its own refactoring features and commands like GoTo Definition and Find All References. Visual Studio also parses in the background, updating its data while you type. Resharper just implements more bells and whistles with that parsing data.
Going from parsing the code to actually generating the assembly is a pretty major step. The internal format of an assembly is too convoluted to allow this to happen in the background without affecting the responsiveness of the machine.
And the C# compiler is still a large chunk of unmanaged C++ code that is independent from the IDE. An inevitable consequence of having to have the compiler first. It is however a stated goal for the next version of C# to provide compile-on-demand services. Getting true background compilation is a possibility.
I don't really have an answer but I just wanted to say that I have been using Eclipse and Java for 4 months now and I love the automatic compilation. I have a very large java code base and compilation happens constantly as I save code changes. When I hit Run everything is ready to go! It's just awesome. It also deploys to the local web server instance (Tomcat in my case) automatically as I make code changes. All this is setup by default in Eclipse.
I hope Microsoft does something similar with .net in the near future.