We Keep Coding

Is There Such A Thinig As a C# Application Link Map Or Something Equivalent?

Is is there a C# build construct available that would allow me to create a link map containing symbols and offsets? I need to debug an application that is throwing an exception when running scheduled out of Task Scheduler.
Here are some details of what is going on: I have developed a C# application on Windows 10 Workstation (non-server). I am trying to run this application on Windows Server 2012 R2, which, like the Windows 10 system, has .net framework 4.5.1 installed.
The application runs with no known errors on the development workstation, whether it is run installed or out of Visual Studio 2012.
However, the application will not run at its scheduled time out of Windows Task Scheduler. This is the error 0xE0434352 -- I have been reading SuperUser and stackOverflow posts about this error -- and the Windows application event log shows an exception has occurred.
However, the offsets in the application event log are not a lot of help without having a map of the executable.
Is creating a link map or equivalent possible?
Here is a link to one description of a linker map for gcc.

in .Net the assemblies are self-describing. A debug database file is useful, but not necessary to describe the objects and how the code is structured. So I would not think a link map are relevant for .net assemblies.
You might want to take a look at dnSpy, this is a combined de-compiler, debugger and assembly editor. It is often useful when trying to debug errors. It is however limited to managed code, so it will probably be less useful if the error is in native code.

How check if an executable is compatible to the installed .NET version

I'm a software tester. I was given an executable to test on a given machine. In the test the executable behaved strangly which could not be explained by anybody.
After a lot of research and debugging I found the cause: The executable that was built for .NET target framework 4.6, but the machine was equipped with .NET 4.5.
This produced some "MissingMethodExeception" for even trivial methods like "string.Format()". Some try-catch caught these exceptions, but treated them in wrong way because nobody had expected them to occur.
A likewise issue has been described here:
Method not found: 'System.String System.String.Format(System.IFormatProvider, System.String, System.Object)
My questions:
Isn't Windows meant to warn me when I'm trying to run an executable that cannot be run properly since the necessary .NET version is not available?
What is the best practise to deal with this problem in general?
(I would have expected something like a checkbox "Dont execute if target network is not available" in VisualStudio?!)

Isn't Windows meant to warn me ...
You'll certainly should get a warning, not from Windows but from the CLR. The dialog looks like this, clicking Yes automatically gets the required framework version deployed and installed on the machine. The CLR performs this check by looking for the [TargetFramework] attribute embedded in the assembly. As noted, run ildasm.exe to verify this attribute. With the expectation that it is either missing or has a low enough value so the dialog does not trigger.
What is the best practice to deal with this problem in general?
It is procedural mistake, the assembly was built wrong. You know with high confidence that the compiler used reference assemblies that are only appropriate for .NET version 4.6. That has to be traced back to the machine that built it, most likely to be a build server. It was not setup correctly, the kind of mishap that is so common when the build engineer cut corners by avoiding using a licensed copy of Visual Studio. Or by favoring freeware tooling, Jenkins is a common scourge.
Beyond getting the [TargetFramework] attribute wrong or missing, this particular mishap is particularly easy to induce. All it takes is using the assemblies in c:\windows\microsoft.net\framework as reference assemblies instead of the proper ones that require a targeting pack and are installed in the c:\program files (x86)\reference assemblies directory. This Q+A has more leads.
Fixing a build server tends to have lots of resistance points, best thing to do as a tester is to file a bug report. You also want to write one for the broken catch-em-all exception handling that made the problem so difficult to diagnose.

To answer the questions:
No Windows is not meant to warn you that the desired .Net Framework is not installed to run this executable. However, Windows will log the error or application crash information in Windows Event Logs.
Re second question...
In general, executables are delivered, deployed or published using Installers. Installer can be configured/written such that they will warn user if .Net framework(required by the exe/dll) is not installed.

How do I deploy System.Management.Automation?

I am helping out with a project that a contractor worked on previously (so I don't have a lot of history for it).
The project builds fine, but when we try to perform some operations, we get a runtime error indicating that System.Management.Automation.dll could not be found.
As a troublshooting measure, we manually installed the dll into the installation directory. We then get an error indicating failure to load Microsoft.Management.Infrastructure.
As nearly as I can tell, these dlls are present in the Microsoft Management Framework download, and possibly in Powershell 3.0.
My question: What is the smallest package that these dlls are a part of, and what is the best way to deploy them for a production software release?
Edit
Just to be clear -- I am not looking to hack/frankenbuild by deploying just those dlls "naked", I am trying to identify the correct redistributable package for those dlls. I just can't seem to work out which one it is.
Edit
If it helps, the nature of the code that we are running is to programmatically create an exchange mailbox.

I think you can't legally redistribute any of those two DLLs alone (discussed for example here for the Automation, you can also check the "Redistributable" section on MSDN for those namespaces). You will have to make sure the target machines have PowerShell and the Management Framework.

Just in case anyone else runs into this problem: We ended up resolving the issue by deploying the Windows Management Framework 3.0, which includes the necessary assemblies. http://www.microsoft.com/en-us/download/details.aspx?id=34595

Periodically seeing the ASP.NET error CS0656: Missing compiler required member

I'm seeing the following error crop up occasionally (seemingly at random) on my web application. We are running Windows Server 2008R2, IIS 7.5, MVC3, .NET 4.5.
It's the same error every time: CS0656: Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.Binder.BinaryOperation'
When this error occurs, it can take anything from a restart of the application pool, to the re-install of our application itself, to fix it.
The error occurs on brand-new VM images (no previous installation of our software), as well as machines that have previously had our software installed on it. The error can occur upon the first run of the application, or when the application has sat long enough for the IIS application pool to recycle the worker process (so it seems).
This is becoming really difficult to deal with, as I've done a ton of research on this error, and tried multiple solutions, with no luck. Also, the random frequency at which the error occurs has made it very hard to troubleshoot. Any insight into this issue, or ideas on possible solutions, would be greatly appreciated. I'm willing to try almost anything at this point.

This looks familiar. If I recall corectly I had to delete the bin directory and rebuild because older versions of dlls were floating around and this class was introduced in .net 4.0
After some research, this site seems to agree: http://our.umbraco.org/forum/using/ui-questions/20474-Missing-compiler-required-member-MicrosoftCSharpRuntimeBinderBinderInvokeMember

Try Forest Cheng Answer:
What version your .NET Framework is?
The ASP.NET MVC 3 run-time components require .NET Framework version 4 and Visual Studio 2010 or Visual Web Developer 2010 Express. Want more information, please look at ASP.NET MVC 3 Release Notes.
Compiler Error CS0656 can be caused by the follow problems:
Your installation of the common language runtime is corrupt.
You have a reference to an assembly that defines a type that is also found in the common language runtime. However, your assembly's type is not defined the way the C# compiler expects.
So check your references to ensure that you are using the correct version of the common language runtime.

We used to have these compilation errors occuring randomly back in the day a long time ago with .net 1 and beyond. This required deleting the contents of the temporary asp.net folder, and finding other rogue dlls that were hanging around, even inside a visual studio cache. In general, flushing the temporary asp.net folder will do it.
Make sure you find all the dlls - the bin folder too obviously, and remember that the dlls are executed from a shadow directory. That is why i recall (also from a long distant memory) that there is a connection to the default appdomain which assemblies are loaded into, especially if you then go loading "the same assembly " but from a different file location.

Make sure you have Microsoft.CSharp reference added in your project.
I added it to my test project and the error disappeared.

Unable to run c#application (using c++ dll) in some PCs

we have created a c# application which calls a c++ dll(sdbm.dll). It is working properly in most of the PCs except some PCs. The dll is created using VC++ 2008 and application is done in VC# 2005. Following are the errors occured when the dll functions are called from the C# application.
Error occured in one PC is as follows
=====================================
Unable to load sdbm.dll :This application has failed to start because the application configuration is incorrect.Reinstalling the application may fix this problem (Exception from HRESULT :0x800736B1)
Error occured in 2nd PC
=====================================
Error Signature
Appname:app.exe Appver:1.0.0.0 Modname:msvcr90.dll Modver:9.0.30729.4148 Offset:0002fc96
Any help would be appreciated

As the others already stated in their comment it seems to be a problem with the dependencies of your sdbm.dll. The simplest way to find out the root cause you should get a copy of DependencyWalker and throw your sdbm.dll into it. First on a machine where it runs without any problems and afterwards start DependencyWalker on one of the problematic machines to see it's output.
It gives you some informations about what DLLs it couldn't found on the current machine. Thous leading you to the problematic libraries.
Nearly always the problem is a missing Visual C++ Redistributable Package (2005, 2008, 2010) or that your library is compiled and deployed as debug version. In this case it will link to the debug versions of e.g. mfcxx.dll by using the mfcxxd.dll. But these debug versions are only installed with the corresponding SDK (or Visual Studio) and not with the redistribution package. Thus leading to problem on the user machine but not no a developer machine.