We Keep Coding

mono-compiled binaries not runable on Windows (unless msbuild is used)

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).

Build openssl from source wtih link option “Integrity Check” in Visual Studio

I want to add "IntegrityCheck" as a command line parameter to the linker when i build openssl 1.1.0 from source. How can i do it?
Thank a lot

If you read the "INSTALL" text file that comes with the source you can find this option:
VAR=value
Assignment of environment variable for Configure. These
work just like normal environment variable assignments,
but are supported on all platforms and are confined to
the configuration scripts only. These assignments override
the corresponding value in the inherited environment, if
there is one.
The following variables are used as "make variables" and
can be used as an alternative to giving preprocessor,
compiler and linker options directly as configuration.
The following variables are supported:
LDFLAGS Flags for the shared library, DSO and
program linker.
So for windows you would need to run the configure script something like:
perl Configure VC-WIN32 LDFLAGS="/INTEGRITYCHECK"
(I'm not sure on the exact syntax of the switch to pass through, so may need to drop the '/')
then run the normal nmake to build it.

Fody looks for intermediate files in the wrong directory

To be able to publish a single .exe I've added Costura/Fody package to my C# project. I've used this package before but now I get the following error message:
MSBUILD : error : Fody: AssemblyPath
"C:\Projects\X\MSBuild\obj\x86\Debug\X.exe" does not exists. If you
have not done a build you can ignore this error.
Finished Fody 4ms.
The strange thing is, is that intermediary X.exe is correctly build here:
C:\Projects\X\src\X\obj\x86\Debug\X.exe
The project I'm working on is fairly large. So we use a couple of MSBuild props files to put everything in the corect output directories. Both building from the command line with MSBuild and building from within Visual Studio works correctly. So I assume our props files are correct. Why is Fody looking in such a weird location for the intermediaries?
which MSBuild variable that Fody might use controls this Intermediary path?

Looking at the code that throws the exception, I see a very simple File.Exists check. It all stems from ProjectDirectory (in a WeavingTask) and you can check the places where the value is used here.
Since I have not used Fody, I can't tell you more than this. I would pay extra attention to the configuration files, since I don't see the ProjectDirectory being constructed anywhere, just injected from somewhere.

How do I disable suppressing a warning for one solution in a TFS build

I'm using TFS 2010 and have a TFS build setup to build our software. Everything is working just fine.
But, we are getting the following warning:
CSC: Assembly generation -- Referenced assembly 'mscorlib.dll' targets a different processor
This is because some of our code is marked as x86 only, and it is being built on an x64 platform. We cannot change the target platform because of third party software we link to.
Also we are targeting the 2.0 framework, which also cannot be changed at this point.
So, I want to simply suppress this error. Seems straight forward enough.
I simply edited the Build template, and added /p:NoWarn=1607. That works.
BUT!
We have ONE solution which is written in VB.net, instead of C#. This causes that one solution to fail with the following error:
vbc: warning number '1607' for the option nowarn is either not configurable or not valid
How do I disable suppressing this warning on that one solution in my TFS build?
I tried to use a <customPropertiesForBuild> tag in my TFSBuild.proj file but I'm probably not using it correctly.
I know I could simply add this to my project files, but we have 37 solutions, each with multiple project files, so I really don't want to do that.

I don't think you can control that suppression from TFS since it is MSbuild complaining during build (and TFS simply calls MSBuild and collects the results).
There's a specific property that tells msbuild to ignore this kind of warning. Simply add the following line to your top Propertygroup in the project file for those projects generating the warning:
<PropertyGroup>
...
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>

You should be able to use Properties metadata on the VB solution's SolutionToBuild item to set NoWarn to an empty value just for that solution:
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../MyVbSolution.sln">
<Targets></Targets>
<Properties>NoWarn=;</Properties>
</SolutionToBuild>
Try that and see if your VB solution will compile without errors.

You can provide a NoWarn Property to MSbuild in TFS Build. One idea also is to edit the build definition, in the "Process" Tab, explore the Advanced=>MSBuild Arguments, and then you supply this "/p:NoWarn=1607" without the qoutes. When you also queue a build, in Parameters Tab=>Advanced=>MSBuild Arguments, enter/p:NoWarn=1607.

How to compile just one file in c#?

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"