8
votes

.Rdlc Report in MVC project - Managed Debugging Assistant 'PInvokeStackImbalance'

Je suis si proche de la mise en service de mon dernier rapport. Je n'ai eu ce problème avec aucun autre rapport. J'essaye de créer un rapport basé sur un enregistrement de base de données. Lorsque je vais créer le rapport par LocalReport et créer les paramètres du rapport, j'obtiens le message d'erreur «Assistant de débogage géré« PInvokeStackImbalance »:« Un appel à la fonction PInvoke »Microsoft.ReportViewer.Common! Microsoft.ReportingServices.Rendering. ImageRenderer.FontPackage :: CreateFontPackage 'a déséquilibré la pile. Cela est probablement dû au fait que la signature PInvoke gérée ne correspond pas à la signature cible non gérée. Vérifiez que la convention d'appel et les paramètres de la signature PInvoke correspondent à la signature non gérée cible. ' Ceci est un rapport .rdlc pour mon projet MVC. L'enregistrement est correct et les valeurs sont insérées, mais lorsque je vais l'afficher / le créer, le rapport génère des erreurs. Sur la ligne â € ˜renderedBytes = localReport.Render (

/* TRACKER_TEST Database Connection ~ Debugging & Testing */
            TRACKER_TESTDataSet dataSet = new TRACKER_TESTDataSet();
            TRACKER_TESTDataSetTableAdapters.Service_Report_FieldsTableAdapter adapter = new TRACKER_TESTDataSetTableAdapters.Service_Report_FieldsTableAdapter();
            LocalReport localReport = new LocalReport();
            localReport.ReportPath = Server.MapPath("~/ReportForms/VirtualService2.rdlc");
            List<TRACKER_TESTDataSet.Service_Report_FieldsRow> report = new List<TRACKER_TESTDataSet.Service_Report_FieldsRow>();
            foreach(var row in list)
            {
                report.Add(adapter.GetDataBy(row.SN1, row.SN2).First());
            }
            ReportDataSource rds = new ReportDataSource("Service_Data", report);
            localReport.DataSources.Add(rds);


            // command specifies whether its a PDF EXCEL WORD IMAGE doc
            string reportType = command;
            string mimeType, encoding, fileNameExtension;

            string deviceInfo =
                "<DeviceInfo>" +
                "   <OutputFormat>" + command + "</OutputFormat>" +
                "   <PageWidth>8.5in</PageWidth>" +
                "   <PageHeight>11in</PageHeight>" +
                "   <MarginTop>0.5in</MarginTop>" +
                "   <MarginLeft>0.3in</MarginLeft>" +
                "   <MarginRight>0.3in</MarginRight>" +
                "   <MarginBottom>0.5</MarginBottom>" +
                "</DeviceInfo>";

            Warning[] warnings;
            string[] streams;
            byte[] renderedBytes;

            renderedBytes = localReport.Render(
                reportType,
                deviceInfo,
                out mimeType,
                out encoding,
                out fileNameExtension,
                out streams,
                out warnings);

            return File(renderedBytes, mimeType);
        }


0 commentaires

6 Réponses :


1
votes

J'ai eu le même problème avec mon rapport. Assurez-vous que votre rapport n'a pas de polices différentes. J'ai changé mon rapport pour avoir la police Arial partout et l'erreur a été résolue.


0 commentaires

1
votes

Fait intéressant, je n'ai expérimenté cela qu'avec Microsoft.ReportViewer.WebForms Version = 15.0.0.0 Je n'ai eu aucun problème avec les versions précédentes. Et ce qui a fonctionné: j'ai fait comme @Srivaishnav Gandhe. J'avais un mélange de polices Cambria et Ariel. J'ai changé tout Cambria en Ariel et hourra - tout a fonctionné. Attention également, cela peut arriver si vous avez défini une culture sur votre définition et que la date de votre rapport est formatée différemment de la culture spécifiée. Il est donc prudent d'avoir une culture réglée sur neutre:


<%@ Register assembly="Microsoft.ReportViewer.WebForms, Version=15.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" namespace="Microsoft.Reporting.WebForms" tagprefix="rsweb" %>


0 commentaires

6
votes

Selon cette réponse , PInvokeStackImbalance est plus un "assistant de débogage" qu'une exception. Donc...

Dans mon cas, comme cela n'empêchait pas le rendu du rapport, j'ai juste désactivé cette exception lors du débogage de mon projet (voir Dire au débogueur de continuer sur les exceptions non gérées par l'utilisateur ). Cela a fait l'affaire pour moi.


2 commentaires

Merci beaucoup, cela a beaucoup aidé après avoir trouvé de nombreuses solutions mais qui n'a pas fonctionné ...


Ce n'est pas une vraie réponse pour ce sujet s'il vous plaît voir ce lien " c-sharpcode.com/thread/... "



8
votes

J'exécute Microsoft.ReportingServices.ReportViewerControl.WebForms 150.1400.0 avec le même problème.

Forcer iis express à fonctionner avec 64 bits résoudra ce problème, étapes:

  • Outils
  • Options
  • Projet et solutions
  • Projets Web et cochez l'option
  • Utilisez la version 64 bits d'IIS Express pour les sites Web et les projets

1 commentaires

Merci! Cette solution fonctionne pour moi :) (VS Professional 2019 Version 16.4.4 + Microsoft.ReportingServices.ReportViewerControl.WebForms.150‌ .1400.0)



1
votes

Je suis tombé sur cette erreur en essayant d'exporter un RDLC au format PDF lors du débogage uniquement. Excel et Word n'ont donné aucun problème.

Il semble avoir commencé lorsque nous sommes passés de ReportViewer.WinForms v14 à v15 il y a quelques mois, mais nous ne l'avons pas remarqué car l'erreur ne se produit pas une fois le projet compilé, confirmant ce que @marcusgambit a mentionné comme étant une "exception de débogage" .

J'ai utilisé la suggestion de @ cyuz dans notre projet WinForms - dans l'onglet Compiler du projet, j'ai décoché la case "Préférer 32 bits" et cela a résolu le problème.

La suggestion de @ brosolomon & @ srivaishnavgandhe sur les polices semble également correcte - Arial et Times New Roman rendent bien tandis que le reste cause une erreur - j'ai testé Calibri, Cambria, Verdana, Wingdings, Tahoma, Segoe.

Le contenu et les données du rapport ne semblent faire aucune différence - il semble que la présence d'une balise dans le RDLC avec une police autre que Arial ou Times New Roman semble être à l'origine du problème.

Si vous êtes intéressé, cet article MS discute du rendu de SSRS en PDF et de la manière dont SSRS tentera d'incorporer une police dans un PDF, mais seulement si des conditions très spécifiques sont remplies ... Je suppose que c'est là que l'échec se produit.


1 commentaires

Bingo! Merci)



2
votes

S'il vous plaît voir ce lien prblem rdlc

Cela devrait être dû à embedFonts dans le fichier Pdf rdlc


0 commentaires