Hey David, I'm convinced at this point it's not a code issue. The dataselect works fine in two different Rock environments and the testing I referred to after is me has shown that known working code. The Person Spouse Name, Address, and Phone Number field all produce the same exception if I repackage them as a new data select (changing the title and class name of course). These are all generated with fresh reports. If you look at the controls methods for the Spouse Select there's nothing there to go wrong!

/// Creates the child controls. ///
/// /// public override System.Web.UI.Control[] CreateChildControls( System.Web.UI.Control parentControl ) { return new System.Web.UI.Control[] { }; } ///

/// Renders the controls. ///
///The parent control. ///The writer. ///The controls. public override void RenderControls( System.Web.UI.Control parentControl, System.Web.UI.HtmlTextWriter writer, System.Web.UI.Control[] controls ) { base.RenderControls( parentControl, writer, controls ); }

Yes, I wanted to confirm that it was "Spouse Name" you were referring to for that very reason - it has no CreateChildControls implementation. So that rules out that possibility.

Did you restart Rock after copying your custom dll?

Hey David,
I've restarted Rock and cleared the cache. The only thing I haven't done is restarted the app pool which I'll do tomorrow.

Ok. If you want to email me your compiled plug-in I would be happy to throw it into my test environment and see if there is any difference in my result to yours?

I've tested an app pool restart with no success. I've sent over my compiled plugin and I'm off to bed. I'll resume investigation tomorrow. If you discover anything post it here so that others can learn!

I couldn't load your assembly in my 3.4 test environment because it is missing some dependencies. If your production server is also on 3.4, you need to be sure that you are referencing the 3.4 dlls (not the 4.0 develop branch) from your assembly, or it will not load correctly in production. This may be the cause of your error.

I'm definitely referencing the 3.4 dlls. I managed to reproduce the error locally (I thought this was by unloading the project in Rockit and just building RockWeb, but I'm not so sure anymore...). I'm running into an exception on line 771 of ReportDetail.ascx.cs. I agree I think it's to do with a reference but I have no idea which (I just tried to load all the .dlls in the RockWeb bin folder as references). Here's a copy of the full exception https://gist.github.com/arranf/44d0dd45c0dced230089#file-gistfile1-txt

Hard to tell what the problem is without seeing the project structure - can you give me access to the source for your Rockit project so I can take a look?

Sure thing. Thanks for taking a look at this by the way, I know it's a bit of a rabbit hole and time siphon! Since my last comment I've scrapped my Rockit project and DB and unzipped a fresh copy, updated to 3.4, and created a new project for the select from scratch. It worked using my local Rockit with the project loaded, and then again with the project unloaded just using the .dll however when I deleted the .dll and rebuilt it I started running into the exceptions again. (EDIT: Clearing the Rockit cache stopped the exceptions but this isn't working on my production install.)

Looking at the line's that are causing an issue I think this might be caching problem with Rock end rather than an issue with references.
Can I send you the fresh .dll along with my Rockit project (what's the best way to share my Rockit project, Github?)?

Yes, if you can put it up on Github, I can grab it from there.

https://github.com/arranf/parentdataselect

Just to update this. David suggested I download the Rock, EntityFramework, EntityFramework.SqlServer, and DotLiquid from my production install and build against those. I've tried that and I'm still running into issues.

Ok, so it looks like dll compatibility is not an issue.
My next guess is that this has to do with loading a report that has components which no longer exist or have been renamed (possibly from a previous version of your add-on?). I've run into this issue before and the fix for it is in the develop branch.
https://github.com/SparkDevNetwork/Rock/pull/1015

This could explain why your code works on the develop branch and not in production.

Using SQL prior to a couple of tests I cleaned up any leftover DataSelect components by deleting them in the EntityType table and any matching attributes in the Attribute table.
I'm presuming that that would rule that out?

In theory, yes... but I'd try applying the fix anyway. I've learned the hard way that presumption is not a good debugging technique! At the very least, it should enable the report to be loaded so you can see any irregularities. Are you able to apply this fix and deploy it to your production server?

Just deployed it.

Here's the Gist for anyone it might be helpful for: https://gist.github.com/arranf/da76961104ebd38bda5d

The report loads, hooray! None of the report controls load but at least the data is now viewable which I can settle for for the moment I think.

When you say "none of the report controls load", do you mean there are errors trying to edit the report, or the fields are simply removed? When you view the existing report, is the data correct? Also, is your custom field available in the Field drop-down? If it is, what happens if you add it to a new Report?

Here is a picture of what I see: http://i.imgur.com/lWXu4Qg.png

I removed all existing report fields before making the change to the block and I cleared the cache and restarted rock. The data is correct in the report and the field is available in the drop down. Sorry for being vague!

Ok, I see. So if you select your field (in Field Type), and add it to the report again, does it work? Or do you get the same result after you save and edit the report again?

The same result. For whatever reason the child controls really don't want to populate...

Ok, this gives me an idea - I will email you a code change to try out.

Okay I tested that code change and it didn't seem to make any visible difference. I cleared the cache, restarted, deleted the field, and readded.

I also fired up an Azure server and tested the plugin on there and I got the same exception that I was getting originally.

Here are the two relevant values from the EntityType table:
Name: Rock.Reporting.DataSelect.Person.ParentsPhoneNumberSelect
Assembly Name: Rock.Reporting.DataSelect.Person.ParentsPhoneNumberSelect, ParentDataSelect, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

This looks fine, provided that your custom assembly is named "ParentDataSelect.dll" and exists in the "bin" directory. Do you have any other copies of the assembly (with different names) stored in the "bin" directory?
Also, is there any possibility you could simply extract the code from the "master" branch and debug against a copy of your production database? This would be the easiest way to identify where the code is failing.

David -- your last comment cracked it. The ParentDataSelect.dll was in the plugin directory as opposed to the bin directory. Every other .dll I've made and uploaded has worked fine from the plugin folder (and one plain refused to work from the bin folder) but this one was fussy. I'm not sure whether any of previous suggested changes were significant as well (as I reported before I ran into the same error locally).

Thanks for persisting with the crazy investigation and I apologise for not thinking of moving it earlier.

Great, I'm pleased to hear you got it working - I know how frustrating these things can be!
Just out of interest, is it possible you had two dlls - an old one in the bin directory and the new one in the plugins directory? I only ask because this could explain the behaviour where the report was viewable, but not editable.

Not possible, I hadn't even considered the bin directory!