SSRS Reports Business Logic - SRSDrillThroughCommon Reference

(0) Share

Report

Posted on by Greg's Mom

Hello,

I have been struggling with an issue for a few days now and haven't had much success resolving it. On most SSRS reports that have a business logic C# project, the business logic project will reference another C# project called SRSDrillThroughCommon. There are several examples of this, one such example is CustGrossMraginbyAccount_NA:

3223.NativeAXReport_2D00_Reference.png

If we edit the CustGrossMarginbyAccount_NAReport.BL project, a solution is generated that contains both the CustGrossMarginbyAccount_NAReport.BL project and the SRSDrillThroughCommon project. We can see there is a reference to the SRSDrillThroughCommon project:

6763.MyReports.png

I am trying to create a cusotmized version of this report but having trouble with my copy of the business logic project maintaining the reference to the SRSDrillThroughCommon project. Here's the copies of the report and the business layer project:

8132.MyReport_2D00_Reference.png

When I edit my business layer project, XYZ_CustGrossMarginbyAccount_NAReport.BL, I add the SRSDrillThroughCommon project to the solution and reference it in the project just as we see in the native AX project:

7181.MyReport_2D00_MissingReference.png

The report builds, deploys, and works perfectly in my development environment. Howver, when I check those projects into TFS and get latest on another machine, the SRSDrillThroughCommon project is not included in the solution that is generated and the reference to SRSDrillThroughCommon is lost:

I saw this article on the issue:

http://blogs.msdn.com/b/dynamicsaxbi/archive/2014/03/20/known-issue-relative-path-errors-when-using-version-control.aspx

I tried what was suggested in the article (making an inoccuous change to SRSDrillThroughCommon project, adding it to TFS, then recreating my BL project with this reference) but I am geting the same result. Does anyone have an idea where I'm going wrong? At this time, my only workaround is to open the BL project on every machine where it is deployed, re-add the SRSDrillThroughCommon project, rebuild, and redeploy. Once this is done, the report works correctly in that environment. It's just not condusive to automated build deployments so I'd like to figure out how Microsoft is able to get those references to persist. Any suggestion would be much appreciated.

Thanks!

*This post is locked for comments

I have the same question (0)

All responses (10)

Answers (0)

Suggested answer

Kumar Gaurav @ MS on at

Like (0)

Report

As I understand your requirement , your need is a drill through report, Not sure why are you trying it through business logic in C#.

Here is a simpler way to create the drill through report

technet.microsoft.com/.../cc639019.aspx

Was this reply helpful? Yes No
Greg's Mom on at

Like (0)

Report

Thank you for your suggestion, Kumar. The report I'm customizing is a native AX report and rather than drilling from one report into another, it's drilling from the report back into AX. They are using this BL project to make the code for drilling back into AX reusable so we don't have to rewrite the logic for opening the customer form each time we have a link, we simply call into a method on the business logic project which has a reference to the SRSDrillThroughCommon project which contains the logic for opening the required AX form. I would still like to find a way to maintain that reference to the SRSDrillThroughCommon project as it's the way Microsoft has created the similar functionality on their reports.

Was this reply helpful? Yes No
Greg's Mom on at

Like (0)

Report

In the end, this is not an issue with drill through action but with referencing another project in an AX C Sharp Project. If AX stores only the project definition, how can visual studio know about the other project reference and relate it to the reference on the first project? I can see the native AX reports doing it successfully but I don't understand how it's possible.

Was this reply helpful? Yes No
Suggested answer

Alex Kwitny 395 on at

Like (0)

Report

Looks like your answer is here:

https://technet.microsoft.com/en-us/library/cc582049.aspx

Was this reply helpful? Yes No
James Chwaszczewski 245 on at

Like (0)

Report

Here's my best explanation, correct or not. I have a distant recollection of this same issue with SSRS reports on AX2009. When using the DrillThroughCommon functionality in custom data methods, the current project needs a reference to the SRSDrillThroughCommon project. All the on-line help indicates how this is done, but the use of TFS is not considered.

When the current project is under version control, the solution directory lives in the local TFS directory. However, the unmodified SRSDrillThroughCommon solution lives in some temp directory. By making a token change to the project (adding a comment) and adding it to TFS, the SRSDrillThroughCommon solution now (also) lives in the TFS directory. Now, the current project has a consistent, valid path to the other project on all systems. Check the path of the SRSDrillThroughCommon reference. I believe it works when SRSDrillThroughCommon is in the local TFS repository/directory along with the other custom projects. Very obscure.

Was this reply helpful? Yes No
Katya Craven on at

Like (0)

Report

I am facing the same issue. Have you found a solution to this?

Was this reply helpful? Yes No
Anthony.H 10 on at

Like (0)

Report

I have the same issue with my builds, Does anyone know how to solve this problem?

I tried running MS build over the csharp projects and node and still the references are missing.

Was this reply helpful? Yes No
Katya Craven on at

Like (0)

Report

Hi Anthony,

Here is how we solved it in our build process:

Our build generation script calls a build flow step ImportVSProject from the TFS build library, which invokes the /Classes/SysTreeNodeVSProject/importProject sys layer static method from AOT. The sys layer method sets the 'ImportWithReferences' option to false causing the references not to load up and thus not to generate .dlls for CSharp projects that reference another CSharp project:

import.set_ImportWithReferences(false);

In order to fix this issue, a usr layer model is imported into AOT overwriting the /Classes/SysTreeNodeVSProject/importProject method in usr layer to set the 'ImportWithReferences' option to true right before ImportVSProject build flow step is invoked.

import.set_ImportWithReferences(true);

Then after all CSharp projects have been imported and complied, the usr layer model is removed to reset /Classes/SysTreeNodeVSProject/importProject method to original sys version.

Hope this helps you.

Was this reply helpful? Yes No
Anthony.H 10 on at

Like (0)

Report

Thanks Katya.

I am using the build activities from joris @ daxmusings.codecrib.com/.../easy-automated-builds-part-1.html

I will modify the class above on my build server as a test and will use the compile individual node activity after the ImportVSproject workflow activity and see if the problem is resolved.

Was this reply helpful? Yes No
Suggested answer

Peter Zaher 40 on at

Like (0)

Report

this issue because the path of assembly

when you edit SRSDrillThroughCommon to your solution it will keep the path of project "SOME_WHERE_IN_TEMP" so you have to reference it as project

Solution:

in AOT right-click on your_ProjectName_BusinessLogic -> click edit

it will show 2 projects (or more if you reference any thing else SRSDrillThroughCommon)

remove SRSDRillThroughCommon and add reference as project

Build -> Add to AOT -> Deploy

Was this reply helpful? Yes No