MsBuild generating obj folder only - bin folder not created

I have a jenkins job that calls msbuild.exe like

/t:Clean /p:WarningLevel=3 /P:Configuration=Release /p:AllowUnsafeBlocks=true

only when I dropped the /t:Clean option, did the folder bin finally get back being created again.

Jenkins is using undesired Windows SDK version

Cumbersome, but what worked for me: https://stackoverflow.com/a/43843099/1219280

Rename msbuild specific assembly only (as opposed to using /p:AssemblyName={...}, which renames all build's project assemblies)

Problem and solution described here.

ILMerge errors (exited with code 1, could find dll, assembly has a value for its PeKind flag that is incompatible...)

After leaving very few spots in my head unscratched (I am environment-conscious, there are those who act with a bit less self restrain and throw their computers through the office's window), I came up with the following solution to ILMerge errors of all sorts. ILRepack is being developed to replace our endeared ILMerge, and although I am sure all of you keep deep feelings (feel free to make them public) about it, my solution was to:

1. backup C:\Program Files (x86)\Microsoft\ILMerge\ILMerge.exe renaming it to, say, _ILMerge.exe 
2. place a copy of ILRepack.exe 
3. rename it to ILMerge.exe  (it follows the exact same ilmerge command line parameters syntax)

 And that's it. Rebuild your solution.
Yes, you are rid of ILMerge. Unbelievable.

Can't force MSBuild to use a different SDK Tools path

My scenario is: my build server, which uses Jenkins as the CI tool, runs on Windows 2008, which does not support the newer Windows 10 SDK. So I tried playing with both SDKToolsPath and FrameworkOverride msbuild command line parameters, but without success (although not the two together). I ended up trying a hack I thought of while the question from this thread (the link points to this very solution I posted there) - overwriting the lc.exe from SDK 7 with the newer LC.EXE from SDK 10. My build finally succeeded. Did not spot any side effects so far...

Building VS projects via command line

An important thing to keep in mind when running msbuild providing properties (in the form of /p:[Key]=[Value]) (for instance, a list of properties useful in building clickonce applications can be found here) is (taken from MSDN):

Global properties are properties that are set by using the /property switch on the command line, or properties that are set by the integrated development environment (IDE) before a project is built. These global properties are applied to all projects that are built by using this Engine.

In other words, if you build a solution with 7 projects (1 start-up plus and 6, say, class libraries), and you provide the AssemblyName parameter like /p:AssemblyName=MyAssembly, you will end up with 7 assemblies with the same name, one with an EXE extension (depending on your project template) and the others with DLL. I, for instance, wanted to rename the final EXE file. Doing this using the approach above did not work for me because of the DLL name conflicts. My scenario uses Jenkins as the CI tool, and I ended up adding a Windows Batch command at the end of the process that renames the $PROJECT_NAME exe only.