DDK Driver - 'Server Status' reports 'Bad Version Info'

[Experimentalist]

I am currently writing an EcoStruxure Geo SCADA Expert driver using the DDK for Geo SCADA Expert version 6.81.7488, Geo SCADA Expert 2019 June 2020 update.

When I start the server the  DBStartup log reports:

[DRV] <Driver Name> Version = 6.81.7488.1, Publisher = Aaawesome Solutions Ltd

[DRV] <Driver Name> ** Bad version info (<Driver Name>)

where <Driver Name> is the name of my driver

The driver is built using .Net Framework 4.5.2

The above log entries are all I have to go on at present.

Has anyone any idea what can cause this error? 

[BevanWeiss]

The DDK 'help' has some info on this, have you walked through all the steps in that?

I'd normally start with the Sample DDK driver.  Just compile this and make sure that it installs and runs correctly.

Then you can modify the appropriate module / driver projects to do what you need of it.

It's been quite a while since I did any DDK development, but there were a couple of other causes that resulted in the Bad Version.  From memory this would happen if your driver (the DBModule portion anyway) was throwing any Exception during initialisation also, meaning it might not be exactly a 'Bad Version'.

Try to cut it down so that you just have the module (i.e. no objects etc) and see if that runs, if it does, then you can slowly add objects (commenting out any interdependencies) until you've got the whole thing working.

[AdamWoodland]

I don't believe it is a driver (exe) issue, too early in the startup process. Looks more like module (dll) issue.

My first guess would be missing or incorrect third party dlls being referenced from your module. Does your driver reference anything beyond the .NET and Geo SCADA dlls? For example Newtonsoft for some JSON handling? If one of those is not in the same path or there's a version mismatch it'll cause the module to fail to load

[AndrewScott · Accepted solution]

The Bad Version Info error occurs if the version information in the driver assembly is missing a version number, a company or a support link: These correspond to the following attributes in the AssemblyInfo file:

• AssemblyCompany
• AssemblySupportLink
• AssemblyVersion / AssemblyFileVersion

https://docs.microsoft.com/en-us/dotnet/standard/assembly/set-attributes 

[Experimentalist]

Andrew

Thanks, that was the issue, is this documented anywhere?

Regards

Andy

[Experimentalist]

Thanks for taking the time to reply. I could find no reference to that in the help file. Which help are you referring to?

[MikeDash]

I know this is an old thread, but this still appears to be an issue.

In the video tutorial by @sbeadle he mentions this is a issue. (See video at 5:00min mark)

https://www.youtube.com/watch?v=tVEIMkj9PnM

But I don't think it is mentioned in any documentation elsewhere.

It might be nice to update the error message in GeoSCADA to something like "Unable to load metadata", and/or provide a few more details in the log.

My issue is, some of those properties are not available in .NET version 4.8 AssemblySupportLink, AssemblyHelpLink, AssemblyUpdateInformation

The example here:

https://github.com/GeoSCADA/Sample-DataFeeder

does not include those 3 attributes, and I get the "Bad Version Error" when I compile it.

When I try to add AssemblySupportLink I get the Visual Studio error:

"Error CS0246 The type or namespace name 'AssemblySupportLinkAttribute' could not be found (are you missing a using directive or an assembly reference?) DataFeeder C:\Users\Parasyn\Source\Repos\Sample-DataFeeder\DataFeeder\Properties\AssemblyInfo.cs"

[AndrewScott]

@MikeDash These properties are not related to the .NET Framework version.

NB. None of the released version of Geo SCADA use .NET Framekwork 4.8, the upcoming Geo SCADA 2021 release will be the first version using .NET Framework 4.8.

C# Example

[assembly: AssemblyTitle("<title>")]
[assembly: AssemblyDescription("<description>")]
[assembly: AssemblyConfiguration("<configuration>")]
[assembly: AssemblyCompany("<company>")]
[assembly: AssemblyProduct("<product>")]
[assembly: AssemblyCopyright("<copyright>")]
[assembly: AssemblyTrademark("<trademark>")]
[assembly: AssemblyCulture("<culture>")]
[assembly: AssemblySupportLink("<link>")]
[assembly: AssemblyHelpLink("<link>")]
[assembly: AssemblyUpdateInformation("<link>")]

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

VB.NET Example

<Assembly: AssemblyTitle("<title>")> 
<Assembly: AssemblyDescription("<description>")> 
<Assembly: AssemblyCompany("<company>")> 
<Assembly: AssemblyProduct("<product>")> 
<Assembly: AssemblyCopyright("<copyright>")> 
<Assembly: AssemblyTrademark("<trademark>")> 
<Assembly: AssemblySupportLink("<link>")> 
<Assembly: AssemblyHelpLink("<link>")> 
<Assembly: AssemblyUpdateInformation("<link>")> 

<Assembly: AssemblyVersion("1.0.0.0")> 
<Assembly: AssemblyFileVersion("1.0.0.0")> 

[BevanWeiss]

---

@MikeDash wrote:

...

The example here:

https://github.com/GeoSCADA/Sample-DataFeeder

does not include those 3 attributes, and I get the "Bad Version Error" when I compile it.

When I try to add AssemblySupportLink I get the Visual Studio error:

"Error CS0246 The type or namespace name 'AssemblySupportLinkAttribute' could not be found (are you missing a using directive or an assembly reference?) DataFeeder C:\Users\Parasyn\Source\Repos\Sample-DataFeeder\DataFeeder\Properties\AssemblyInfo.cs"

---

I don't believe those are Geo SCADA Expert Drivers.  They are just client applications, so they don't need to match versions 1:1 with the Geo SCADA Expert server (nor expose the Assembly properties mentioned by Andrew).

It's important to note the distinction between a Client Application and a Driver in the Geo SCADA Expert world.

In general, Client Applications are much nicer to develop (the build/deploy/debug cycle is much easier, and faster).

In terms of functional capabilities, they are really quite similar.

It's more in the coupling that they are different, the driver is tightly coupled into Geo SCADA Expert (in terms of in service configuration and also in terms of the build / deploy process), so it's really only for that reason that you might favour the creation of a driver instead of just a client application.

Given the Geo SCADA Expert release cadence, developing (and supporting) out of tree drivers is becoming quite labour intensive.  Unless there's really a strong reason to have some development as a driver (i.e. its behaviour/configuration would need to be synchronised between servers and has a reasonably high turnover in configuration data... like it's for a currently unsupported protocol or similar.. in which case the limitations of the Simple Drive model might cause frustrations anyway), you'd likely be better off developing it as a stand alone application (whether user driven, or service model).