Develop Reference

What does the environment variable IGNORE_NORMALISATION_GIT_HEAD_MOVE do?

I have a C# code base that uses GitVersion.MsBuild. Sometimes my Jenkins build server gives me this error:
GitVersion.BugException: GitVersion has a bug, your HEAD has moved after repo normalisation.
To disable this error set an environmental variable called IGNORE_NORMALISATION_GIT_HEAD_MOVE to 1
This often happens when building a feature branch that is not based on the latest master (i.e., master has moved since the feature branch was made).
The error message describes a suggested fix/workaround, but I am hesitant to do this because I don't know what environmental variable IGNORE_NORMALISATION_GIT_HEAD_MOVE does, and I cannot find a description of it anywhere.
If I set IGNORE_NORMALISATION_GIT_HEAD_MOVE to 1, what side effects does this have?
Thanks in advance!
EDIT: I asked the same question in an issue on GitVersion's GitHub.

According to the maintainers of GitVersion, this variable just suppresses a BugException that otherwise gets throw in this situation.
See issue here: https://github.com/GitTools/GitVersion/issues/2934

How to Debug "Source Not Available" WPF error

I have a WPF application that has started failing with the following error at start:
System.InvalidOperationException: ''{DependencyProperty.UnsetValue}' is not a valid value for property 'BorderBrush'.'
This exception was originally thrown at this call stack:
[External Code]
This is not very forthcoming about what has caused the error. I have tried turning on the CLR Exceptions and restarting as per This Page, but it did not give any more information; I turned on the disassembly, but don't understand what it means. Turning on "Just My Code" debugging and all the Exception Settings as per this page got slightly more in the exception stack trace:
System.InvalidOperationException
HResult=0x80131509
Message='{DependencyProperty.UnsetValue}' is not a valid value for property 'BorderBrush'.
Source=WindowsBase
StackTrace: at System.Windows.DependencyObject.GetEffectiveValue(EntryIndex entryIndex, DependencyProperty dp,
RequestFlags requests)
This exception was originally thrown at this call stack:
System.Windows.DependencyObject.GetEffectiveValue(System.Windows.EntryIndex, System.Windows.DependencyProperty, System.Windows.RequestFlags)
but none of this gives me (that I can see) any information about what code is failing. I have got down to deleting various bits and re-starting the app, but it is extremely time-consuming and I can't help but wonder - is there something else I should be doing.
Is there any way I can find out which bit of code is failing, or any clues (e.g. search terms to look for in my code, clues as to whether it would be a .xaml or a .cs page, places to look in the Exception details, anything) that might help narrow down the location? For instance, is this something that would only be returned by a failed attempt to override the template defaults in wpf, or might it be caused by one of my windows - Is it likely to have come from a style maybe?
Basically, other than seeing that there seems to be a place where I should be setting the BorderBrush and am not, I have no idea how to find what error I need to fix - and since it is a missing thing, I don't know how to find it. Any leads, hunches or advice will be greatly received!
This is a WPF Windows Application, writing in Visual Studio 2019 using .NET 4.8

So it turns out that there really is no way to find out clearly where the error was, but through a process of deleting files, clearing out references and reinstating, I was able to find the problem.
There was a reference to a static resource in a connected .DLL that no longer existing since the .DLL was republished without checking. The change in name there meant that a resource was not found and the unset value was sent to the Dependency Property. It would be lovely if Microsoft were able to provide some sort of check on the location of problematic resources.

Error 21 error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0004c7)

I have a large windows forms project that was ported from MFC to WinForms. The business logic is all in C++ so we have a couple of assemblies written using C++/CLI to wrap the unmanaged code. The original port was done using Visual Studio 2005 and .net 2.1. We have migrated it to VS2010 and .net 4.0. We are currently maintaining both versions. Everything was fine until I added a header file for a class so I could utilize one of its methods. Just adding the header caused the error:
Error 21 error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0004c7). c:\XXXX\Project\AAAAPI.obj
Project.API
There are two clases involve3 here:
AAAAAPI.cpp with header AAAAAPI.h
BBBBAPI.cpp with header BBBBAPI.h
if AAAAAPI only included AAAAPI.h
and BBBBAPI.cpp only includes BBBBAPI.h everything links and runs as expexcted
But when I add AAAAPI.h to BBBBAPI.cpp I get the above error. What is interesting is it is not compalining about BBBAPI.OBJ but AAAAPI.OBJ
Also If I remove AAAAAPI.h from BBBBAPI.h (which works as above) and add BBBBAPI.H to AAAAPI.cpp it works. So the same two headers in one cpp filr work and in another they do not work.
I hope this is enough information for you to understand my problem. The code involved it part of a very large system and it would be difficult to add more detail about what the code is doing. Just note that all I have to do is add a header file which is just a class definition, no executable code to cause the errors.
Any halp would be greatly apreciated.

I've gotten this error when I had a #define that affected a class definition, and the class definition ended up different depending on which file it was included from. Check that you don't have any #defines or similar that might be affecting your classes.
You'll have to post code if you want a firmer answer. It's impossible to diagnose code issues without seeing the code.

Cannot instantiate 1 out of 2 classes in DLL from COM client

I’m working with a .NET 4 application written mostly in C#. The application has a user interface, but it also has an automation interface that allows the features of the application to be exploited directly from a .NET client. It also supports automation via COM, and for this there are “COM adapter” DLLs that present the classes/methods in the “real” DLLs in a COM-friendly way.
For example, let’s say the API for the bulk of the functionality is in a DLL called “Alpha.DLL”: a .NET client can simply reference that DLL directly, but a separate DLL called “Alpha.Com.DLL” is provided for use by COM clients (e.g. VBA).
There are 3 such COM adapter DLLs, and while two work fine, I simply cannot get the last one to work correctly.
The problem DLL only has two classes defined within it, and while I can instantiate one of them from a COM client such as VBScript, I get an error when I try to instantiate the other. The error I get is:
-2146234304 (0x80131040) Automation Error
I can instantiate the same class from .NET code, just not from a COM client.
I’ve tried using FUSLOGVW.EXE to look for assembly-loading errors, but there don’t seem to be any (and in any case, the fact that I can instantiate the other class from the same DLL suggests that it’s not the DLL itself that can’t be found/loaded?).
I’ve tried attaching a debugger and putting a breakpoint inside the constructor for the offending class, but it doesn’t get hit when I try to instantiate the class from VBScript. (A breakpoint in the constructor of the class that works does get hit).
I’ve checked the registry entries for the class I’m trying to instantiate, and I can’t see any problem. The GUIDs and version numbers all seem to match up.
I’m all out of ideas, and at the end of my tether, and I’d be extremely grateful for some help…

-2146234304 (0x80131040) Automation Error
The common problem with using .NET code from a COM client like VBA is that .NET exceptions get rather difficult to diagnose. You have to make do with an often cryptic HRESULT error code, you don't get the Holy Stack trace to see how code blew up. This exception is a doozy like that, it is FUSION_E_REF_DEF_MISMATCH, you can find these HRESULT codes in the CorError.h SDK include file.
You'd normally get the easier to interpret exception message "The located assembly's manifest definition does not match the assembly reference". And the stack trace to tell you what type caused this exception so you'll know what assembly is the problem. Nothing like that when this failed when called from VBA.
It is otherwise an every-day .NET mishap, the CLR found your assembly but its [AssemblyVersion] does not match the reference assembly's version that your code was compiled with. COM certainly increases the odds that this can go wrong, the version is recorded in the registry when you register the assembly with Regasm.exe. Forgetting to re-register if you do it by hand instead of letting the build system take care of it is a very easy oversight. Also very easy to copy dependent DLLs in the client EXE's directory, so the CLR can find them, and forgetting to update them.
Fuslogvw.exe does show this kind of mishap, hard to guess why you don't see anything. The backup plan is to use SysInternals' Process Monitor. It also shows you how the client is reading the registry, another thing that often goes wrong in COM. And you'll see it locating the DLL from the registry key so you'll have a shot at guessing why it found an old one.
Stay out of trouble by using the GAC, often necessary anyway to help the CLR to find dependent assemblies and to solve COM's rather severe DLL Hell problem. And strongly consider using the .NET 4 AppDomain.FirstChanceException event. Good to log exceptions before they turn undiagnosable in the COM client.

please check first
your com dll is placed into GAC
you dont't forget about regasm
http://www.jagjot.com/2014/01/register-c-vb-net-dll-regasm-gacutil/
check cpu architecture
does your com dll depends on anything outside GAC?

Aaargh. I found the problem. I said in my question:
I’ve checked the registry entries for the class I’m trying to instantiate, and I can’t see any problem. The GUIDs and version numbers all seem to match up.
...which was true. However, what I had not noticed was that in the registry definition of one of my classes, the public key token was wrong.
This explains why one class could be instantiated while the other could not, and possibly why there was nothing in the FUSLOGVW log (because the assembly was loaded OK when an instance of the "good" class was created).
Thanks for your help, Hans and Dimzon.

ImDisk API issue in .NET

I have been working on implementing ImDisk into my C# project, where I can create RAMDisk on the fly. Unfortunately due to absolutely no examples, I am at a bit lost as to how to resolve this issue.
I am receiving the error Unable to find an entry point named '_ImDiskFindFreeDriveLetter#0' in DLL 'imdisk.cpl'. which, after Google searches, is apparently from not initiating an object. However, ImDiskAPI has no constructors, and cannot be initiated in that manner, so I am at a bit of a stand-still. When I attempt to initialize an instance, I get The type 'LTR.IO.ImDisk.ImDiskAPI' has no constructors defined
Does anyone have any idea what I can do to get this going?

The error indicates that there is a DLL missing.
You need to place the ImDisk.cpl file into your application's directory.
The managed wrapper library needs the ImDisk.cpl file to function properly.
Hope, this helps.