Appel DLL C++ avec le CRL 2.0

**AliHome** · 22/05/2015, 18h31

Bonjour à tous,

Je vous explique mon problème :

J'ai une DLL en C++, LibFlac permettant de traiter les fichiers audio FLAC (http://www.rarewares.org/files/lossl...-1.3.1-icl.zip), que j'exploite à l'aide d'une autre librairie que voici :
https://code.google.com/p/practicesharp/

Le problème, c'est qu'en utilisant la DLL "NaudioFLAC" (de practicesharp) sur un projet utilisant le .NET 4.0 et 4.5 par exemple, j'ai une erreur un peu bizarre sur un appel à la DLL C++.
Or, si je change le framework en 3.5, utilisant bien le CLR 2.0 tout fonctionne correctement.

Ma question est, comment forcer l'utilisation du .NET 3.5 (CLR 2.0) juste pour la DLL NAudioFLAC tout en gardant mon projet en .NET 4.0 ?
J'ai trouvé une solution disant de mettre ça dans le fichier app.config :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
  </startup>

mais ça ne fonctionne pas.

Merci d'avance pour vos réponses.

**Médinoc** · 25/05/2015, 11h41

j'ai une erreur un peu bizarre

:bouledecristal:

Je ne sais plus trop quelles sont les difficultés exactes pour les interactions entre DLLs prévues pour différentes versions du framework (ou pire, les DLLs prévues pour interagir avec deux versions différentes d'une même DLL).
Je dirais au pire, si tout le reste échoue, faire du out-of-process avec WCF...

**AliHome** · 25/05/2015, 14h33

Envoyé par Médinoc

:bouledecristal:

Je ne sais plus trop quelles sont les difficultés exactes pour les interactions entre DLLs prévues pour différentes versions du framework (ou pire, les DLLs prévues pour interagir avec deux versions différentes d'une même DLL).
Je dirais au pire, si tout le reste échoue, faire du out-of-process avec WCF...

c'est vrai que j'ai pas précisé je pensais pas ça utile, j'imagine que personne ici n'a déjà utilisé cette librairie, mais voici l'erreur :

"FLAC: Could not process single!"

Sur cette fonction à priori :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[DllImport(DLLName, CallingConvention = CallingConvention.Cdecl)]
        public static extern bool FLAC__stream_decoder_process_single(IntPtr context);

Pour la solution WCF c'est pas envisageable malheureusement, étant donné la perte de performance...

**Médinoc** · 25/05/2015, 15h01

Ce message d'erreur, est-il visible dans le code qui appelle cette fonction, ou bien vient-il de la fonction elle-même?

**AliHome** · 25/05/2015, 16h16

Non à vrai dire ce message n'est pas d'une grande utilité, je vous montre d'où il provient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
FLACCheck(
                        LibFLACSharp.FLAC__stream_decoder_process_single(m_decoderContext),
                        "process single");

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
        private void FLACCheck(bool result, string operation)
        {
            if (!result)
                throw new ApplicationException(string.Format("FLAC: Could not {0}!", operation));
        }

Donc ça ne vient pas de la DLL C LibFlac.

D'ailleurs quand on regarde la doc, c'est pas détaillé du tout.

https://xiph.org/flac/api/group__fla...122cf7f987f856

Return values
FLAC__bool false if any fatal read, write, or memory allocation error occurred (meaning decoding must stop), else true; for more information about the decoder, check the decoder state with FLAC__stream_decoder_get_state().

**AliHome** · 25/05/2015, 16h29

Peut-être qu'il faut aussi se poser la question de savoir pourquoi l'appel à cette fonction marche avec le CLR 2.0, et pas avec le 4.0 ? J'ai toujours lu partout que le CLR 4.0 était rétrocompatible avec le 2.0...

**bacelar** · 25/05/2015, 16h50

j'ai une erreur un peu bizarre sur un appel à la DLL C++.

Pouvez-vous être un peu plus précis ?

**AliHome** · 25/05/2015, 16h52

Envoyé par bacelar

Pouvez-vous être un peu plus précis ?

Oui je la décris juste en dessous dans un de mes messages

**bacelar** · 25/05/2015, 23h26

Oups, quelques messages de loupés.

Comme il s'agit d'Open-Source, le débugging dans les sources de la bibliothèque pourrait nous donner de précieux complément d'informations, non ?

**AliHome** · 27/05/2015, 19h01

Envoyé par bacelar

Oups, quelques messages de loupés.

Comme il s'agit d'Open-Source, le débugging dans les sources de la bibliothèque pourrait nous donner de précieux complément d'informations, non ?

Oui tout à fait, j'essaye depuis plusieurs jours de trouver l'origine de l'erreur, en vain.

Voici les sources si quelqu'un se sent de déboguer :

https://github.com/xiph/flac
Il faut à priori utiliser nasm pour compiler, et également une lib d'ici :
https://github.com/xiph/ogg

Je pense que le problème doit venir du callback (stream_decoder.c > ligne 2976 ?) entre la DLL C et le client (.NET), sauf que je ne vois pas où ça capote.

**AliHome** · 28/05/2015, 17h17

Je vous met ici les bouts de code concernés, peut-être que certains ici seraient en mesure de dire si le CLR 4.0 l'interprète différemment du 2.0 etc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
        private void FLAC_WriteCallback(IntPtr context, IntPtr frame, IntPtr buffer, IntPtr clientData)
        {
            // Read the FLAC Frame into a memory samples buffer (m_flacSamples)
            LibFLACSharp.FlacFrame flacFrame = (LibFLACSharp.FlacFrame)Marshal.PtrToStructure(frame, typeof(LibFLACSharp.FlacFrame));
 
            if (m_flacSamples == null)
            {
                // First time - Create Flac sample buffer
                m_samplesPerChannel = flacFrame.Header.BlockSize;
                m_flacSamples = new int[m_samplesPerChannel * m_flacStreamInfo.Channels];
                m_flacSampleIndex = 0;
            }
 
            // Iterate on all channels, copy the unmanaged channel bits (samples) to the a managed samples array
            for (int inputChannel = 0; inputChannel < m_flacStreamInfo.Channels; inputChannel++)
            {
                // Get pointer to channel bits, for the current channel
                IntPtr pChannelBits = Marshal.ReadIntPtr(buffer, inputChannel * IntPtr.Size);
 
                // Copy the unmanaged bits to managed memory
                Marshal.Copy(pChannelBits, m_flacSamples, inputChannel * m_samplesPerChannel, m_samplesPerChannel);
            }
 
            lock (m_repositionLock)
            {
                // Keep the current sample number for reporting purposes (See: Position property of FlacFileReader)
                m_lastSampleNumber = flacFrame.Header.FrameOrSampleNumber;
 
                if (m_repositionRequested)
                {
                    m_repositionRequested = false;
                    FLACCheck(LibFLACSharp.FLAC__stream_decoder_seek_absolute(m_decoderContext, m_flacReposition), "Could not seek absolute: " + m_flacReposition);
                }
            }
        }

Dans le constructeur de la classe on a ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

m_writeCallback = new LibFLACSharp.Decoder_WriteCallback(FLAC_WriteCallback);

La déclaration :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

private LibFLACSharp.Decoder_WriteCallback m_writeCallback;

Le delegate :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
public delegate void Decoder_WriteCallback(IntPtr context, IntPtr frame, IntPtr buffer, IntPtr userData);

Voilà pour le callback du coté de la classe C#. Après recherche j'ai pu constater que le FLAC_WriteCallback ne retourne pas ce qu'il devrait, à savoir "FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE", comme montré ici dans le code en C de la librairie FLAC :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (write_audio_frame_to_client_(decoder, &decoder->private_->frame, (const FLAC__int32 * const *)decoder->private_->output) != FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE) return false;

J'ai vérifié en testant, en .NET 3.5 on a bien FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE, et en 4.0 on a des chiffres aléatoires (valeur d'un pointeur ?). Le problème est donc directement lié à la valeur retournée par le callback, sauf que je ne vois pas où c'est géré en fait

Merci pour votre aide !

**AliHome** · 28/05/2015, 17h22

Veuillez m'excuser pour tout les messages, j'ai oublié de préciser une dernière info. La partie du code dans "write_audio_frame_to_client_" ou on voit bien que ça retourne le résultat du callback :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

return decoder->private_->write_callback(decoder, frame, buffer, decoder->private_->client_data);

Promis j'arrête maintenant

**bacelar** · 29/05/2015, 14h21

Pas de soucis pour les gros repost.
Juste un EDIT du message pour éviter les petits repost.

J'ai du mal à voir d'où sort la valeur de retour de "FLAC_WriteCallback" vu que ça retourne un void.

Il y aurait pas un souci dans la définition du delegate Decoder_WriteCallback ?

Si je me rappelle bien des conventions d'appel C sous Intel, il récupère la valeur de retour de la fonction en haut de la pile, donc, pour moi, un truc "aléatoire".

C'est quoi la signature de la fonction "write_audio_frame_to_client_" ?

J'ai vérifié en testant, en .NET 3.5 on a bien FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE

C'est peut-être tombé en marche en .NET 3.5.

**AliHome** · 29/05/2015, 14h45

Oui en fait je me suis rendu compte qu'on pouvait éditer après coup

Voilà c'est bien ça qui me chiffonne, c'est un void, donc je ne comprend pas comment la valeur est renvoyée en fait, Et étant donné que ça fonctionne en .NET 3.5...

La déclaration :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

FLAC__StreamDecoderWriteStatus write_audio_frame_to_client_(FLAC__StreamDecoder *decoder, const FLAC__Frame *frame, const FLAC__int32 * const buffer[])

C'est peut-être tombé en marche en .NET 3.5.

Qu'entendez vous par là ?

**bacelar** · 29/05/2015, 19h56

"FLAC__StreamDecoderWriteStatus" je suppose que c'est un int ou un truc du genre ?

Il y a clairement un problème dans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
public delegate void Decoder_WriteCallback(IntPtr context, IntPtr frame, IntPtr buffer, IntPtr userData);

Ça sort d'où ?
Qui en est l'auteur ?

Le code natif veut 3 paramètres (passé dans la pile en convention C standard, avec ceux à droites empilé en premier) et un retour en code erreur (int).
Le code managé veut 4 paramètres et ne renvoie rien, ça sent pas bon.

Qu'entendez vous par là ? (tombé en marche en .NET 3.5. )

C'est que le fait que de l'extérieur, on ne voit pas de bugs ne veut pas dire qu'il n'y a pas de bug latent.

Il est fort probable que la version 4 du framework face plus de contrôle et de cloisonnement, pour des problèmes de sécurité d'exécution, par exemple, que la version 3.5.

Pour moi, on est sur la trace d'un bug latent, et il a toujours été là, tapis dans l'ombre.

**AliHome** · 31/05/2015, 18h47

Alors pour le code C# ça vient de ce lien que j'ai mis au début :
https://code.google.com/p/practicesharp/

Pour la déclaration :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
/** Return values for the FLAC__StreamDecoder write callback.
 */
typedef enum {
 
	FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE,
	/**< The write was OK and decoding can continue. */
 
	FLAC__STREAM_DECODER_WRITE_STATUS_ABORT
	/**< An unrecoverable error occurred.  The decoder will return from the process call. */
 
} FLAC__StreamDecoderWriteStatus;

Et en effet où est passé le 4ème paramètre, mystère, surtout que dans le header on a ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

typedef FLAC__StreamDecoderWriteStatus (*FLAC__StreamDecoderWriteCallback)(const FLAC__StreamDecoder *decoder, const FLAC__Frame *frame, const FLAC__int32 * const buffer[], void *client_data);

Tout le code C vient de la fondation Xiph qui développent le format FLAC (j'ai aussi donné le lien git de leurs sources).

Pour moi, on est sur la trace d'un bug latent, et il a toujours été là, tapis dans l'ombre.

Vous pensez que le problème viendrait de quel coté, la librairie de Xiph en C ou le C# ?

Merci à vous

**bacelar** · 31/05/2015, 23h42

Je ne suis pas un spécialiste du P/Invoke, j'ai toujours tendance à mettre une couche C++/CLI entre le code managé et le code natif.
Pouvez-vous vérifier avec un outils comme celui ci-après, si la signature C# correspond ?
http://blogs.msdn.com/b/bclteam/arch...an-patten.aspx

Je serais assez étonné que cela corresponde.

**AliHome** · 02/06/2015, 00h47

A vrai dire moi non plus, et j'ai tenté d'ouvrir la dll avec votre outil ça ne fonctionne pas j'ai une erreur, à moins que je n'ai pas bien compris son utilisation.

EDIT : j'ai retenté de deboguer, et bizarrement cette fois ci l'espion sur Visual Studio me donne la valeur correspondant au retour, et surprise ce n'est pas aléatoire mais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

FLAC__STREAM_DECODER_WRITE_STATUS_ABORT | 2970270 (2970271)

Pour rappel :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
/** Return values for the FLAC__StreamDecoder write callback.
 */
typedef enum {
 
	FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE,
	/**< The write was OK and decoding can continue. */
 
	FLAC__STREAM_DECODER_WRITE_STATUS_ABORT
	/**< An unrecoverable error occurred.  The decoder will return from the process call. */
 
} FLAC__StreamDecoderWriteStatus;

EDIT2 : complément d'informations

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
/// <summary>Constructor - Supports opening a FLAC file</summary>
        public FLACFileReader(string flacFileName)
        {
            Console.WriteLine("FLACFileReader: " + flacFileName);
            // Open the flac file for reading through a binary reader
            m_stream = File.OpenRead(flacFileName);
            m_reader = new BinaryReader(m_stream);
            // Create the FLAC decoder
            m_decoderContext = LibFLACSharp.FLAC__stream_decoder_new();
 
            if (m_decoderContext == IntPtr.Zero)
                throw new ApplicationException("FLAC: Could not initialize stream decoder!");
 
            // Create call back delegates
            m_writeCallback = new LibFLACSharp.Decoder_WriteCallback(FLAC_WriteCallback);
            m_metadataCallback = new LibFLACSharp.Decoder_MetadataCallback(FLAC_MetadataCallback);
            m_errorCallback = new LibFLACSharp.Decoder_ErrorCallback(FLAC_ErrorCallback);
 
            // Initialize the FLAC decoder
            if (LibFLACSharp.FLAC__stream_decoder_init_file(m_decoderContext,
                                               flacFileName, m_writeCallback, m_metadataCallback, m_errorCallback,
                                               IntPtr.Zero) != 0)
                throw new ApplicationException("FLAC: Could not open stream for reading!");
 
            // Process the meta-data (but not the audio frames) so we can prepare the NAudio wave format
            FLACCheck(
                LibFLACSharp.FLAC__stream_decoder_process_until_end_of_metadata(m_decoderContext),
                "Could not process until end of metadata");
 
            // Initialize NAudio wave format
            m_waveFormat = new WaveFormat(m_flacStreamInfo.SampleRate, m_flacStreamInfo.BitsPerSample, m_flacStreamInfo.Channels);
 
            Console.WriteLine("Total FLAC Samples: {0}", LibFLACSharp.FLAC__stream_decoder_get_total_samples(m_decoderContext));
        }

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
        public delegate void Decoder_WriteCallback(IntPtr context, IntPtr frame, IntPtr buffer, IntPtr userData);

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
[DllImport(DLLName, CallingConvention = CallingConvention.Cdecl)]
        public static extern int FLAC__stream_decoder_init_file(IntPtr context, string filename, Decoder_WriteCallback write, Decoder_MetadataCallback metadata, Decoder_ErrorCallback error, IntPtr userData);

**AliHome** · 03/06/2015, 16h58

Après avoir testé, je me suis rendu compte que le problème viendrait de cette partie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
lock (m_repositionLock)
            {
                // Keep the current sample number for reporting purposes (See: Position property of FlacFileReader)
                m_lastSampleNumber = flacFrame.Header.FrameOrSampleNumber;
 
                if (m_repositionRequested)
                {
                    m_repositionRequested = false;
                    FLACCheck(LibFLACSharp.FLAC__stream_decoder_seek_absolute(m_decoderContext, m_flacReposition), "Could not seek absolute: " + m_flacReposition);
                }
            }

Il y aurait-il une différence entre le CLR 2.0 et 4.0 dans la façon de gérer le lock qui pourrait induire un problème ? Je ne suis pas un spécialiste du multi threading, du coup j'ai du mal à isoler le problème. En tout cas je sens que je me rapproche du problème, ce qui est d'ailleurs plus cohérent car il ne se produit qu'en changeant le .NET Framework utilisé.

**Médinoc** · 03/06/2015, 17h03

Je ne crois pas qu'il y ait vraiment de différence de ce côté-ci. Es-tu sûr que le lock commence et finit bien là où il faut?
Et qu'en est-il des autres locks sur le même objet?

Appel DLL C++ avec le CRL 2.0

C++/CLI

Discussions similaires

Partager

Partager