Visual Studio Metrics doesn't reqognize .gha - expects .dll

rhino5

#1

Trying to run Calculate Code Metrics on a GH Component project in Visual Studio 2015, but VS can’t find the expected .dll among the compiled files. This problem seems to stem from a GH project producing a .gha-extension instead of a .dll. (see error message below)

Perhaps this could be solved by using a double extension like “Component .gha.dll” ?

Anyway, I’ve tried to find a place where to configure VS what file extension to expect but I couldn’t find any. Anyone else knowing how to handle this?

.
Error message by VS when running “Analyse|Calculate Code Metrics|For Solution” :

Project: RILGH_Utils
Assembly: …\RILGH_Utils\RILGH_Utils\bin\x64\Debug\RILGH_Utils.dll
Message: No code metrics are available for this project because because the target file ‘…\VS\RILGH_Utils\RILGH_Utils\bin\x64\Debug\RILGH_Utils.dll’ is missing. Please rebuild the project and calculate code metrics again.

.
.


Edit: OK, it just struck my mind that I could temporarily rename the .gha file into a .dll instead, and only then run the analyze commands. I just tried it and it seems to work.

// Rolf


(Nathan 'jesterKing' Letwory) #2

You can update your project file build step such that instead of renaming the dll to gha it would just copy. That way you’ll have both.


#3

Thank you @nathanletwory, that works perfectly.

For others reading this post, the following change does the trick. In the .csproj-file, modify by disabling or removing the “Erase” command, like so :

Before :

< PostBuildEvent>
    Copy "$(TargetPath)" "$(TargetDir)$(ProjectName).gha" 
    Erase "$(TargetPath)"
< /PostBuildEvent>

After :

< PostBuildEvent>
    Copy "$(TargetPath)" "$(TargetDir)$(ProjectName).gha" 
    <!-- Erase "$(TargetPath)" -->
< /PostBuildEvent>

Or, remove the line containing “Erase” althogether:

< PostBuildEvent>
    Copy "$(TargetPath)" "$(TargetDir)$(ProjectName).gha" 
< /PostBuildEvent>

With this change both a .dll and a .gha remains in the target folder.

// Rolf


(Nathan 'jesterKing' Letwory) #4

The better way would af course be to put all functionality in a separate library (dll) such that the gha is essentially just the glue between the functionality and GH. That should also help in designing and implementing clean code (from API perspective.

/Nathan