Nous cherchons à développer une mise à niveau de notre application ASP.NET existante à MVC3. Notre application actuelle est uniquement basée uniquement et la mise à niveau sera neutre du navigateur, c'est-à-dire qu'il doit fonctionner dans IE8 +, Firefox, Chrome et Safari. P>
Le principal problème que nous avons est que nous disposions de plusieurs rapports basés sur SQL Reporting Services 2008 R2 et nous utilisons le contrôle de la visionneuse de rapport 2010. P>
Nous ne voulons pas vraiment utiliser cela à l'avenir, car: P>
J'aimerais vraiment le remplacer par une alternative (même si sa visualisation est basée et que nous devons pirater une solution avec MVC) mais je n'ai pas pu en trouver un. Existe-t-il un contrôle alternatif qui rend compte des rapports de services de rapport? C'est le spectateur que nous voulons remplacer, pas Rs. P>
3 Réponses :
Je suis d'accord avec vous. C'est vraiment un contrôle de buggy. J'ai joué avec mes paramètres de DOCTYPE pour modifier ma sortie HTML. P>
Si vous pouvez essayer des commerciaux, consultez le contrôle Telerik. P>
Regardez également cette discussion: P>
http://siddhumehta.blogspot.com/2011/ 07 / SSRS-ReportViewer-webpart-contrôle.html p>
J'ai également trouvé des fuites de mémoire lorsque vous essayez de faire de gros volumes de rapports via le visualiseur de rapports dans WPF. Voir jenasysdesign.com.au/dnn/blogs/tabid/71/post/149/...
Vous pourrez peut-être simplement afficher la version HTML et définir les commandes à lier par le service dans une URI de repos à la place. EG:
http:// (servername)/(ReportServer)/(PathtoReport)&(Parameter=Value)&rs:Command=Render
Nous voulions intégrer les SSR avec un site Web existant, mais je ne voulais pas utiliser l'interface utilisateur de la SSRS (puisqu'il s'agit de son propre site Web) et nous ne voulions pas utiliser les contrôles de vue du rapport (bien que nous ayons une ASP. Site Web NET, les contrôles de la visionneuse de rapport ont des options limitées pour le faire faire ce que vous voulez). La solution qui a fonctionné pour nous était: p>
Appelez le service Web SSRS pour renvoyer une liste de rapports et déposez les valeurs dans une liste déroulante. P> LI>
Lisez le chemin de rapport de la liste déroulante et obtenez le service Web SSRS qui renvoie les paramètres du rapport sélectionné. P> LI>
Construire des contrôles d'entrée basés sur ce qui est revenu dans # 2. p> li>
Les utilisateurs fournissent les valeurs d'entrée et soumettent le formulaire. P> li>
La page transmet les valeurs au service Web SSRS et récursent un document PDF, Excel, document Word basé sur ce que l'utilisateur a demandé. p> li> ol>
Ce n'était pas si difficile (il a fallu <40 heures au code et test) et fonctionne vraiment bien. Le plus gros problème que nous ayons soutient différentes versions du service Web SSRS lorsque vous passez d'une version de SSRS à une autre. P>
Je suppose que si vous vouliez produire les rapports en tant que HTML et la pompe à l'interface utilisateur, vous pouvez le faire aussi. P>
Évidemment, si vous souhaitez que tous les utilisateurs modifient les propriétés du rapport, créez des abonnements, etc. - vous aurez des travaux supplémentaires à faire. p>
Pour mettre à jour mon propre commentaire pour les autres jusqu'à présent, n'en avez pas trouvé un pour MVC, mais je suis envisagé dans le moteur de services Web pour Rs. Cela pourrait être une option.
Je suis occupé à essayer de fuir le spectateur de rapport aussi. J'ai réussi à obtenir la plupart des fonctionnalités requises à l'aide du service WCF. Le seul problème que j'ai confronté est de gérer des rapports liés. Veuillez partager vos expériences car il s'agit de l'un des aspects les plus importants de l'intégration des SSR à des applications Web.
Je n'ai pas essayé, mais une fois que vous avez suivi l'API pour des rapports liés, il semble tout droit: msdn.microsoft.com/en-us/library/ms152864.aspx