I've got a C# project that I need compiled to a native binary. I've read here:
http://www.mono-project.com/AOT
That Mono can precompile an assembly to one of two options:
--aot : A precompiled image (essentially the same as Ngen as it looks to me)
--aot=full: A fully compiled to native binary instance of the original .exe
I am fairly sure I'm understanding those right, but could be wrong about the --aot=full option.
However, when I run:
mono.exe --aot=full --verbose program.exe
I get no output, the last modified date on the executable remains the same, and no files are generated. I've also tried just as a test:
mono.exe --aot --verbose program.exe
I get the same result; no output, no image file or files in general, nothing.
Am I missing something here?
You should probably make a bug report. AOT info is normally displayed even without --verbose. With --verbose you should get a LOT of prints. Another possibility is that you have broken Mono installation.
Nevertheless if you want to produce native executable binary, you should use mkbundle rather than AOT.
You don't want --aot, you want mkbundle.
--aot tells mono to precompile some code rather than use the jit compiler, it does not give you a fully machine-code binary. For this you need mkbundle.
Related
I have some trouble using binaries created by Mono csc compiler on Windows. It's a basic CLI project for Framework 4.0 with a few internal assemblies. Previously, we were building this tool with xbuild and the result was usable everywhere. Now xbuild cannot be used (internal policy reasons) so I added a script which calls csc commands directly. The .exe can still be run in Mono but on Windows I get:
Method not found: "System.String System.String.TrimEnd(Char)".
at …
This is surprising. When I investigate that function call in code, it's like:
subDirectory.Replace('/', Path.DirectorySeparatorChar).TrimEnd(Path.DirectorySeparatorChar)
So, that signature is not available in .NET but .TrimEnd(params Char[]) is. And the compiler should normally convert between a single argument and params array.
My csc command line looks like:
csc /debug:full /debug:portable /optimize- /define:"DEBUG;TRACE"
/langversion:latest .v4.0.AssemblyAttribute.cs
/out:bin/Debug/myproject.exe /target:exe *.cs /.cs
/r:bin/Debug/some_custom_depencency.dll
/r:bin/Debug/some_other_custom_dependency.dll …
/nostdlib /r:System.dll /r:System.Xml.Linq.dll
/r:System.Data.DataSetExtensions.dll /r:System.Data.dll
/r:System.Xml.dll /r:System.Core.dll /r:mscorlib.dll /warn:4
It's more or less the same what msbuild does, just using shell's wildcard expansion. And the .v4.0.AssemblyAttribute.cs file is the one I grabbed from xbuild temp files (where it defines the .NET Framework version).
I checked the old and new exes (msbuild and custom calls) in dotPeek and everything looks identical except for the signature. File is runnable with Mono itself.
I'm running out of ideas now, can anyone suggest something to try or change or knows the reason immediately?
Found the problem, it was right upfront. msbuild/xbuild uses absolute paths to the framework assemblies but my call didn't. I assumed that it would consider information from AssemblyAttribute but apparently it doesn't, mono linker happily goes to whatever its default framework is, and is not reporting mismatches at build time.
The solution: change the /r:... paths to the ones in /usr/lib/mono/4.0-api/ (or whatever the framework setting defines).
I know about $(BaseIntermediateOutputPath), but I need the complete path.
For some reason, Microsoft decided to use "$(BaseIntermediateOutputPath)$(ConfigurationName)\" for AnyCPU, but "$(BaseIntermediateOutputPath)$(PlatformName)\$(ConfigurationName)\" for x64.
I have a command that needs to access the .resource files in the intermediate output path. However, since one platform needs $(PlatformName) and the other does not, I can't just use one command. My current solution is to use a condition (Condition=" '$(Platform)' != 'AnyCPU' "). It would be a lot more clean if I just had access to the full intermediate dir, like with $(IntDir) in C++.
I'm sure that the next question is why I don't just use AnyCPU. I have a managed C++ project as part of my solution, and I get dire warnings if I dare reference an x64 project from an AnyCPU project. So why don't I just use x86 and not use AnyCPU? Because the IDE is 32-bit, and the designer will not work with x64 projects. Not only that, but instead of just telling you that, you get cryptic error messages and stack traces in the designer that you have to search here for the meaning of.
$(IntermediateOutputPath).
Look inside c:\Program Files(x86)\MsBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets.
Line 33: <IntermediateOutputPath Condition="'$(IntermediateOutputPath)'==''">$(IntDir)</IntermediateOutputPath>
Try one of these:
$(IntermediateOutputPath)
$(IntDir)
I recently published a library targeted to build for .Net4.5. Now that Windows 8 is out, I'd like to essentially build for that platform too.
Unfortunately, some of the code I used in the original library hasn't made it into the RT core, however I've spent most of today doing the adjustments and testing with a copy of the code.
Essentially I've now got two code files, an original, and a copy with about 5 lines updated and using a different namespace. I've done conditional compilation for Debug/Release, however I've never done a batch compile.
My ideal goal would be to combine these files, perhaps using compiler flags and #if, to make the code more manageable. Then compile to Library.WinRT.dll and Library.x86.dll. I don't mind having 2 different projects, symbolically linking the files, but I really don't want duplicate code.
Any suggestions on how I can go about doing this? Anyone got experiences they'd like to share?
I think you answered your own question. Use compiler flags, link to files between projects (not using the file system's symbolic links, but rather add existing files from one project to the other as link - using the drop down next to the "Add" button in the open file dialog). What do you mean by batch compile? Do you want to build from command line? Then you can do something like this:
msbuild /verbosity:quiet /fl /t:Rebuild /p:Configuration=Release Library.WinRT\Library.WinRT.csproj
msbuild /verbosity:quiet /fl /t:Rebuild /p:Configuration=Release Library.NET45\Library.NET45.csproj
I'm writing a really small application in C# and I need to include an .cs file with some class. How do I do that? I'm looking for some equivalent to PHP's "include file" or Python's "from file import something". Obviously "using" is not enough and the file has to be somehow linked. And I really don't want to start some new super-huge-totally-useless project using MonoDevelop or VisualStudio, I would like to stay with simple gmcs and command line.
You simply include both file names on the command line and ensure that the namespaces are the same or that the namespace of the included file is imported via a using statement or via fully qualified references. Then the command line for compilation looks like this:
gmcs mainFile.cs includeFile.cs
Note that the mono command line is designed to support the exact same syntax (with a few additions) as the Microsoft compiler so this is true for both of them.
Fundamentally this is what the project files and visual studio are doing (albeit going through an in memory msbuild equivalent)
There are two ways to "include" a file in .NET (and Mono)
Compile several files together.
gmcs mainFile.cs includeFile.cs
then files are then compiled together to a single assembly
Compile the includeFile to a separate assembly and reference that from the main assembly
gmcs -target:library includeFile.cs
gmcs -r:includeFile.dll mainFile.cs
this way you get two assemblies
In VC++ I can press CTRL+F7 to compile a single file, or right click on a source file ot compile it.
Is it possible to compile a single file (or current file) in C#?
I would like to for example know if my current file has any errors in it without having to compile everything.
For single .cs file compile + run:
In VS 2008, go to "Tools" > "External Tools"
Click on "Add"
Title: Run CSC (or whatever you want)
Command: C:\Windows\system32\cmd.exe
Arguments: /c C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe /target:winexe $(ItemPath) && $(ItemFileName)
Initial directory: $(ItemDir)
Check Use Output Window
Apply + Ok
Go to Tools and choose "Run CSC"
If this doesn't work, verify that your paths for cmd and csc match.
No it is not possible to do this in C#.
Unlike C++ a C# file cannot be reasonably compiled on it's own to determine if it has any errors. C++ achieves this through #include statements which allows a .cpp file to understand the declaration of types available. These declarations define the structure of types the current file depends on and allows the compiler to ensure they are used according to specification.
This process is handled implicitly in C#. The set of declarations available is simply the set of all declarations in all compiled files which are otherwise accessible. There is no way to forward declare dependencies in the manner C++ does and hence no way to ensure they are being used correctly within a single file.
A Visual Studio add-in tool like ReSharper is a very good investment for this situation.
ReSharper performs continuous background solution-wide code analysis and will report issues by conveniently displaying a bar next to your code file\document scrollbar which has red\orange lines denoting any lines of code that have issues\errors. The displayed lines are click-able to navigate to the line in question and also have tool-tips detailing what the exact problem is:
http://www.jetbrains.com/resharper/features/code_analysis.html#Continuous_Code_Quality_Analysis
http://www.jetbrains.com/resharper/features/screenshots/50/marker_bar.png
The issues\warnings that ReSharper can check for are configurable (but it has excellent configuration out-of-the-box), and can denote anything from errors which would cause the code not to compile to more subtle issues where it has detected a possible null method call result which has not been explicitly checked for.
In command line:
%windir%\Microsoft.Net\framework\V3.5\csc.exe /target:library File.cs
You could reasonably attach this to the solution explorers context menu through Tools->External Tools
set the arguments to /target:library $(ItemPath)
something like that might do what you want. Though the file would have to depend on no other files in the project or in referenced binaries aside from what's in the GAC.
Shift-F6 will compile the current assembly, which is almost what you want.
Yes it's possible. You can call the compiler directly using command prompt. i.e.
Create single file 'hello.cs'
Open the Visual Studio command prompt
Navigate to the directory that has 'hello.cs'
Run csc hello.cs
Execute your single file by typing hello.exe
This will at least tell you whether a single file compiles or not. You can find more information here: https://msdn.microsoft.com/en-us/library/78f4aasd.aspx
Yes, this can be done using the Mono .NET Framework. At the command prompt, run mcs path/to/file.cs.
From the Mono docs:
To compile, use csc:
csc hello.cs
Note: csc compiler is not available on all platforms or in very old Mono versions, in such cases use mcs instead.
The compiler will create “hello.exe”, which you can run using:
mono hello.exe
Using Visual Studio 2022 csc.exe
navigate here in PowerShell:
PS C:\Program Files\Microsoft Visual Studio\2022\Community\Msbuild\Current\Bin\Roslyn
compile single file into dll or exe:
.\csc.exe -target:library -out:"C:\Users\quick\OneDrive\Desktop\C#\PerpetualCalendar\PerpetualCalendar.dll" "C:\Users\quick\OneDrive\Desktop\C#\PerpetualCalendar\PerpetualCalendar.cs"
cs file needs Main Method
.\csc.exe -target:exe -out:"C:\Users\quick\OneDrive\Desktop\C#\PerpetualCalendar\PerpetualCalendar.exe" "C:\Users\quick\OneDrive\Desktop\C#\PerpetualCalendar\PerpetualCalendar.cs"