ConLib reference list empty

[NC Software]

In the help menu of the admin I wanted to review the conlib reference and it's not populating. I dug into the code and it appears this may not be available for WAP as it's searching for .ascx.cs files. In that case if WAP you may want to hide this menu item.

Code: Select all

if (di.Exists)
            {
                files = di.GetFiles("*.ascx.cs", SearchOption.AllDirectories);

[NC Software]

I'm guessing then it breaks other areas of the admin such as ConLib pickers? I was wondering why when reviewing various layouts no controls showed.

[NC Software]

Well, this should be interesting. It appears the entire ConLib system and its integration in Admin is shot in WAP. Unless dev can do reflection on the assembly to look for the ConLibs instead of the file system.

[mazhar]

We develop against WAP mode and in my current development install if I choose to see ConLib Reference then it does populate the controls. I am using Administration -> Help -> Conlib Reference menu link.

[NC Software]

In your WAP solution are the .cs files in the file structure? If you use WEB DEPLOY those files are not deployed to the server. They are compiled into the assembly so your code is broken in a deployed scenario. Please test your product DEPLOYED to a server, production environment, not in a development scenario.

[mazhar]

Yes you are correct. Development environment does have code files since they are required. I quickly performed a test by simply dropping .cs files, since its WAP mode code is already compiled so website seems to be working but conlib reference is not. I am going to report this.

[NC Software]

I think you're going to have to use Reflection to resolve this issue and probably better attribute usage going forward for descriptions vs. code documentation elements.

I was wondering if I was going to have to switch to WSP which I really want to avoid as I'd rather have one DLL vs. thousands of per page DLL's for performance and code access security and many other reasons I believe WAP is better and WSP was a mistake by Microsoft. Also for a better compilation situation in Visual Studio and integrity on and on. So having thought this through and how I can salvage this (WAP) is that as long as I am connected to my production database after release I will still be able to handle layouts in admin via localhost in Visual Studio where the *.cs files do reside and therefore I can make the selections and changes locally. Those ConLib changes should still resolve I assume and will have to test in my server side deployable setup (thanks to AC for that setup). So again, as long as Admin config changes for layouts or ConLib references are made from a local web solution run, it should work. The ConLib's exist server side and are really just .ascx file based loads, the UI element can be resolved and still be used going forward with this pattern.

Simpler explanation: Make layout UI changes on the local machine connected to the production database until CommerceBuilder.UI can be addressed to resolve this. I consider this a blocker from an engineering standpoint as your system will be unusable for WAP configs for people that don't use Visual Studio and have a deployed solution but for me I can continue to move forward as I use Visual Studio and can get around this locally. The other option which is a very bad and not a maintainable option is to FTP up the .cs files to the production server so the metadata is available for CommerceBuilder.UI to read.