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.
Related
What is the difference between Assembly Definitions and namespaces in Unity?
Is writing your own namespaces mean you manually add AsmDefs in code?
Is code compile time faster in one or the other, or all the same?
Apples and oranges.
Namespaces allow you to partition code to avoid name collision. You can have multiple per assembly.
Assembly Definitions (ASMDEFs) is a purely Unity creation and simply a means to speed up compilation time. They are best thought of as the equivalent to a project file in Visual Studio in the respect of speeding compilation time. Rather than recompiling all your code, only the ASMDEF whose files were modified are recompiled whilst any follow-on ASMDEFs or non-ASMDEF code are simply “re-linked” (if applicable).
NOTE: Don’t make the mistake of thinking ASMDEFs only benefit the Unity build operation (the thing that takes 10 minutes+). They don’t. They are mainly for decreasing the delays experienced in the Editor where you are waiting to hit the Play button.
Since the output of an ASMDEF is an assembly, naturally whatever you can do in c# code also applies such as confining the code to one or more namespaces.
With regards to compilation times, it doesn’t take much to push Unity over the edge whereby delays of minutes or more are not unheard of. This always surprises new Unity users even those experienced with VS. Unity takes considerable more time to compile the same amount of code compared to VS however there is a subtle explanation as to why. Once you understand the mechanics you realise that comparing compilation times is also apples and oranges.
The reason is that, by default, ASMDEFs are disabled for user code and when Unity decides to compile your code, it does so for all platforms including x86, x64, Editor etc irrespective of your OS bitness or whether you intend to click that Play button. This also applies to any 3rd party code you have.
For this reason, even if you don’t intend to use ASMDEFs in your own code, create a child folder for all the Standard Unity Assets and 3rd party code and create a corresponding ASMDEF for it. Don’t forget to limit the ASMDEF to just the platforms you need for the maximum benefit in speedy compilation.
I'm writing a UWP program to detect colors from LEDs, this program runs on a Raspberry Pi 3 with Windows 10 IoT with attached display.
What the program does is take a reference image with the LED turned off, then take a image from the LED turned on.
Both images are converted to the same pixelformat and then are cropped to a smaller size, in which only the LED is shown (both the reference and the lighted LED).
Then those picture parts are converted to grayscale wich is followed by creating a difference picture of the two, so that only pixels that changed from the reference to the lighted LED are shown.
To do so I use the NuGet-Package portable.AForge.imaging. The code is shown below.
LEDBildNeu = LEDBild.Clone(PixelFormat.Format24bppRgb);
ReferenzbildNeu = Referenzbild.Clone(PixelFormat.Format24bppRgb);
Crop cropping = new Crop(new System.Drawing.Rectangle(Convert.ToInt32(x), Convert.ToInt32(y), 100, 100));
CroppedLED = cropping.Apply(LEDBildNeu);
CroppedReferenz = cropping.Apply(ReferenzbildNeu);
Grayscale grayscale = new Grayscale(0.2125, 0.7154, 0.0721);
GrayscaleReferenz = grayscale.Apply(CroppedReferenz);
GrayscaleLED = grayscale.Apply(CroppedLED);
Difference difference = new Difference(GrayscaleReferenz);
Differenzbild = difference.Apply(GrayscaleLED);
This code works fine as long as im in debug mode, all of the functions are working.
However when i change to release mode, i get this error while building:
1>C:\Users\morsch.nuget\packages\microsoft.net.native.compiler\1.7.2\tools\Microsoft.NetNative.targets(697,5): warning : MCG : warning MCG0007: Unresolved P/Invoke method 'ntdll.dll!memcpy' for method 'System.Byte* AForge.SystemTools.memcpy(System.Byte*, System.Byte*, System.Int32)'. Calling this method would throw exception at runtime. Please make sure the P/Invoke either points to a Windows API allowed in UWP applications, or a native DLL that is part of the package. If for some reason your P/Invoke does not satisify those requirements, please use [DllImport(ExactSpelling=true) to indicate that you understand the implications of using non-UWP APIs.
1>C:\Users\morsch.nuget\packages\microsoft.net.native.compiler\1.7.2\tools\Microsoft.NetNative.targets(697,5): warning : MCG : warning MCG0007: Unresolved P/Invoke method 'ntdll.dll!memset' for method 'System.Byte* AForge.SystemTools.memset(System.Byte*, System.Int32, System.Int32)'. Calling this method would throw exception at runtime. Please make sure the P/Invoke either points to a Windows API allowed in UWP applications, or a native DLL that is part of the package. If for some reason your P/Invoke does not satisify those requirements, please use [DllImport(ExactSpelling=true) to indicate that you understand the implications of using non-UWP APIs.
When I run the code in release mode and get to the part where the difference picture is created, I get the exception
System.TypeLoadException: 'Unresolved P/Invoke method 'memcpy!ntdll.dll' from this method. Please look for this method in build warnings for more details.'
According to this 'memset' and 'memcpy' are not supported by UWP. My questions now are:
Why does the program run in debug mode without any problems even when those two entry points are not supported, but as soon as i turn to release mode i get the exceptions?
Is there a workaround for the problem?
I already tried to use
[DllImport("ntdll.dll", EntryPoint = "memset")]
and
[DllImport("ntdll.dll", EntryPoint = "memcpy")]
But either I did it wrong or it just don't work that way.
I know I could just program a workaround in which I check the pixels manually and create a new image, but I wanted to solve that problem if possible.
Finding the correct combination of directives can be a very frustrating and time consuming process. Here is additional information that I received from Microsoft via email, hope this helps:
Helpful links:
https://devblogs.microsoft.com/dotnet/net-native-deep-dive-dynamic-features-in-static-code/
https://learn.microsoft.com/en-us/dotnet/framework/net-native/runtime-directives-rd-xml-configuration-file-reference
https://learn.microsoft.com/en-us/dotnet/framework/net-native/runtime-directive-policy-settings
The analysis we do to get your application ready to be ahead of time compiled is quite extensive. We need to generate code for various generic types, reflection callable wrappers, serialization information, marshalling stubs etc etc. In come cases (as you could imagine) we end up generating more than is strictly necessary due to run away combinatorics. It’s completely possible that some fiddling with our heuristics can get you application to a place where it compiles without any loss of functionality.
Practically speaking, there’s two ways to manipulate the behavior of the compiler. One is through some of our compiler flags available through dropping elements into your csproj. The other is making edits to your applications Properties\Default.rd.xml file.
Compiler flags
There are a wide range of flags available but here’s a couple that may help out:
<ShortcutGenericAnalysis>true</ShortcutGenericAnalysis> - Can help stop runaway analysis of generic types and reduce overall generation requirements.
<UseDotNetNativeSharedAssemblyFrameworkPackage>false</UseDotNetNativeSharedAssemblyFrameworkPackage> - Eliminates one of the linking boundaries the compiler has to fight with. I actually suspect turning this off will make things worse not better but whole program optimizers are hard to reason about but rebuilds are cheap enough to try.
Runtime Directives
There’s lots of reading above but the tl;dr is that this file is read by the compiler and can contain lots of hints about what we want it to do or ignore etc. The overall syntax of the file is also included in the reading above but I don’t think we’re very clear about the one special directive that’s include by default:
<Assembly Name="*Application*" Dynamic="Required All" />
This directive says: “Please save/generate enough information so that all user types can be inspected and created via reflection.” Where ‘user types’ means any type in an assembly that isn’t signed with the .NET key token. So, basically everything that isn’t explicitly .NET Framework. This in leads to lots of bloat but also makes it so most folks don’t ever have to think about these things. In cases where we don’t have enough information, you’ll get runtime exceptions like MissingMetadataException or TypeLoadException or NullReferenceException. Each instance will require a bit of code inspection and fiddling with directives to get patched up. This can be an annoying a fragile process. All that said, the analysis engine is quite sophisticated and you’ll get lots and lots of things ‘for free’ without the special directive or any hassle. It’s entirely possible that your app runs great with just a little bit of tweaking.
Okay, the goal now is to remove this directive but still have a working application. There’s two approaches that have tradeoffs, so I’ll describe both and let you decide if either methodology suits you. Roughly here’s what the two workflows look like:
Start from nothing.
a. Remove the special Application directive
b. Build the app
c. If the build fails, email us, else…
d. Test the app and see if you hit any runtime errors
e. If you do you’ll need to look at the error location and see if adding some directives can help then head back to (b).
f. If you find no errors, you’re done! Hooray!
Start from everything
a. Remove the special Application directive
b. Get a list of the full set of dlls for your project, for example by inspecting here: obj[architecture]\Release\ilc\in
c. For each dll, add a Dynamic directive. They’ll look like: <Assembly Name="ASSEMBLYNAMEWITHOUTEXTENTION" Dynamic="Required All"/>
d. Comment out some subset of these libraries
e. Build the app
f. If the build fails again in RHBIND go to (d)
g. Test the app and see if you hit any runtime errors
h. If you do you’ll need to look at the error location and see if adding some directives can help then head back to (e)
i. If you find no errors, you’re done! Hooray!
I found a solution which worked:
Instead of downloading the portable.AForge package with NuGet i downloaded the portable.AForge from GitHub.
Find the .cs-file called SystemTools.cs (located in AForge/Sources/Core/).
Open it with any .cs editing porgram, now search for all code like
#if !MONO
...
#else
and remove it.
This clears the use of memcpu() or memset() from ntdll.dll.
Save the SystemTools.cs, create the library and add the AForge-Package manually to the application.
After the change it worked without any problems.
I will briefly tell you the situation.
I got a C# project which uses some DLL created in C++.
Now, separately, I also have a C++ project, which was used to create that DLL some time ago.
Now, I wanted to debug the C++ DLL during running the C# project.
I enabled "Enable Unmanaged Code Debugging" in my C# project.
I started debugging C# project and stepping into some functions alongside.
All seemed to be ok. When I reached a function which belonged to C++ DLL,
it asked for the source of the C++ file, I had to browse to my C++ project.
(Before I think it complained about some .pdb files).
Now, I managed to step into the C++ function also, but as I step over and over, some of the data structures in that function don't seem to be populated with the data, e.g., please see screenshot below
You can see the blob data structure is empty, and same happened with DataParser (it was showing it had 0 items inside, whereas in code above you can see there are multiple items being added to it).
I would really appreciate some help, what is going wrong here? And where I could have done mistake. How can I debug this C++ DLL so that I also see what values are assigned to its variables currently?
Maybe my way of debugging this C++ DLL is wrong? The fact that the C# project is using an already created DLL, and I have this C++ project which was used to create this DLL some time ago - the fact that they are separate, maybe that has to do something with it also?
PS Before I had to make changes like this to C++ project and lower toolset because I use VS2012 (strange if project was created using VS2013 though because I think it is old project). Also the project uses lot of manually written other C++ classes. Maybe that is the problem also and somehow the compiler can't retrieve their values and definitions?
What are the steps in general to debug a C++ DLL file in a setup like I have?
EDIT: PPS. Also some other interesting facts I have seen. If I click F11(Step into) on the DataParser.Add function for example, not necessarily I am taken to the body of that function, it shows me body of other function (which might be somehow related to it).
Also if I press F10 say after first time Request.Add is called, it jumps over multiple Request.Add lines, and moves to the fifth one for example.
EDIT2: Also before I step into C++ code it is showing me warning that "the source is different version than the one that was used to create a DLL". Is this a problem?
Module and PDB
There is a link between a module (.dll/.exe) and the debug database (.pdb). This link is established via a timestamp and a checksum that is present in both files. Visual Studio checks the correctness of those, otherwise it will complain and not stop at breakpoints at all.
While other debuggers such as WinDbg have commands to turn that feature off, Visual Studio doesn't have such a feature and requires active manipulation (such as Chkmatch) to turn off the checmsum verification. As long as you didn't use such a tool, your debugging symbols are fine.
PDB and source
There is also a link between the debug database (.pdb) and the source. This link is established by file name and line numbers. As you can guess, your source code will not modified during compilation, so the source code does not contain any checksum or timestamp that could be verified.
Therefore, the source may have changed and the line numbers may not even match roughly any more. There are several reasons for line numbers to get broken. I have answered a similar question before and listed the following reasons for line number changes although the code itself did not change:
code reformat, which e.g. sorts the methods by visibility, so complete methods are moved
code reformat, which e.g. breaks long lines at 80 characters, usually this moves things down
optimize usings (R#) which removes 30 lines of unneeded imports, so things move up
insertion of comments or newlines
How to debug
Restore the exact source code of that version, if you can.
Debug completely without source, just by PDB information. This way you can keep the binary components, if that's important (e.g. if a bug can only be reproduced with that version)
Rebuild all modules to make the code match the modules again. That way you lose the binary and the problem may not reproduce any more.
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.
In C#, we have 2 modes to build projects : Debug and Release, I wonder if Java has the same thing. I am using IntelliJ IDEA as Java IDE and so far I haven't seen anywhere to configure a build mode like in VS IDE.
javac
-g Generate all debugging info
-g:none Generate no debugging info
-g:{lines,vars,source} Generate only some debugging info
You can choose to include debug symbols in the compiled classes (this is the default) or to not do so. There is not much benefit to not doing that. The jar files will be a little smaller, but the performance benefit is minimal (if any). Without these symbols you no longer get line numbers in stack traces. You also have the option to include additional symbols with local variable names (by default there are only source file names and line numbers).
java
-ea[:<packagename>...|:<classname>]
-enableassertions[:<packagename>...|:<classname>]
enable assertions
You can also enable assertions at run-time (default is off), which is sometimes useful during development and testing. This does have a performance impact (if the code in question did indeed make use of assertions, which I think is uncommon).
Regardless of any of these settings, the JVM always allows you to attach a debugger.
What Java does not have is conditional compilation where completely different code would be compiled based on some external setting. The closest you can get is something like public static final boolean DEBUG_BUILD = true; somewhere in your code and use that in if statements. This will actually make the compiler exclude code that becomes unreachable, but you have to set this constant in the source code.
It is normal practice in Java to release everything is a manner which can be debugged. For some projects requiring obfuscation, they could have a release build, but I have never seen this in 12 years of developing Java.
Things such as assertions and debug messages are usually turned off at runtime for a production instance but can be turned on at any time (even dynamically) if required.
IMHO it is best practice to use the same build in every environment, not just the same source but the same JARs. This gives you the best chance that, if it works in test, it will work in production and if you have a problem in production, you can re-produce it in test.
As so much Java code is written this way, the JIT is very good at optimising dead code which is never called. So much so that IMHO most of the micro-"benchmarks" where Java out performs C++, is when the benchmark doesn't do any thing and the JIT is better at detecting this. IMHO, C++ assumes the developer is smart enough not to write code which doesn't do anything.
You're asking for different kinds of builds to compile in different things I guess. For example to have Debug.WriteLine and Console.WriteLine.
"No, Java doesn't have an exact match for that functionality. You could use aspects, or use an IOC container to inject different implementation classes." stole this from the following question: Conditional Java compilation
(there're other nice answers for you there)