Docuware with .NET

Does anyone have experience with the connection of extend and MS-Docuware via .NET?
I would like to physically download documents from Docuware.
With netdefgen I do not really get on with it because generating the copy modules produces errors.
And of course I have no experience with .NET.

I do not have experience with Docuware, but I do have experience wtih .NET and NetDefGen giving errors. This is my specific situation, which may or may not be like yours, but may help you with troubleshooting.

My NET program uses a 3rd party grid component, which is available in a few DLLs. The 3rd party company offers their products for NET Framework 2.0 and Framework 4.0, which show up in separate categories in the Toolbox in Visual Studio. Some components and features are available in 4.0 and not in 2.0, but I believe that most of the components use exactly the same class names between the versions. The only difference is that the DLL names contain the Framework version--<componentName>.4.dll or <componentName>.2.dll.

When I run my program through NetDefGen, I get errors. I spent several days going back and forth with Support before we got the situation resolved. First, the copy module was generated correctly. There was no issue with that. The error was coming from the second part of the process, which was generating the events module. NetDefGen executes ilasm.exe to produce the events DLL, and that's what was generating the error. And the error was because the components from the 3rd party component were being accessed using their file name, which contains the Framework version but which is not part of the class name. Islasm.exe does not know how to resolve that, so it returns an error, which is then output by NetDefGen. Support suggested that I run ilasm.exe manually (from the command line), and I have success doing that.

Here are the steps: I have several classes in my program namespace. When I run NetDefGen, I make sure to select only the class that interfaces with my COBOL program. The next screen shows all the public methods and properties, with events at the bottom. If you have no events and you are getting errors from NetDefGen, this explanation is not the answer to your problem. If you have events, keep reading. While on this screen (or the previous or next one), click Settings from the menu at the top. This screen allows you to select some options for convenience, and also to make sure you are running the correct version of IL Assembler. There is a note that NetDefGen supports .NET version 1.1 and 2.0. I am using it with 4.0 and it works fine (I use extend 10.0.0). Under the section Diagnostic Aides, I click the box to "Keep the generated event source". This will keep the .evt file which is created by NetDefGen and usually deleted upon completion. Then I click Save, and complete the NetDefGen process, getting the "Generation Failed" message. Not to worry.

Look for the .evt file in the same folder where you specified your copy file to be placed. I copy that file to the \\bin folder of my COBOL installation. Then I open the file (it's a text file), and I delete the component version from the class name (this is for my particular 3rd party component) and save the changes. If you try this, you will likely not have to edit your .evt file. I open a command window, navigate to my COBOL \\bin folder, and run the following:
ILASM.EXE /DLL /DEBUG /OUTPUT="<name of your output event file.dll" "<name of your input event file>.evt"

I name the output file the same as my input file, so if my input file is "LookupNet.UserControl1.evt", my output file is "LookupNet.UserControl1.dll". You can Google to get more info on ilasm.exe--it's from Microsoft, and these are the options I use. You can also use /QUIET which doesn't display processing messages, but I like to see what's going on. And once you get it working, you probably don't need /DEBUG. When this command executes successfully, the output DLL is there in the \\bin folder where it needs to be. I seem to remember having to copy ilasm.exe into \\bin. Be cautious--all different versions of ilasm.exe are named the same, so make sure you are using one for the correct Framework of your NET module.

If you have a newer release of extend, you may need to use this command which includes /RESOURCE:
ILASM.EXE /DLL /QUIET /resource:"C:\\Program Files (x86)\\Micro Focus\\extend 10.1.1\\AcuGT\\bin\\template.res" /DEBUG /OUT="C:\\Temp\\AmortControl.UserControl1.dll" "C:\\Temp\\AmortControl.UserControl1.evt"

This is a rather cumbersome process, but it was the best (only) way for me to get COBOL and NET talking to each other.

Does anyone have experience with the connection of extend and MS-Docuware via .NET?
I would like to physically download documents from Docuware.
With netdefgen I do not really get on with it because generating the copy modules produces errors.
And of course I have no experience with .NET.

Thanks for the detailed description.
In my case that did not help, but that's definitely interesting information.
I had downloaded the .NET components with the NuGet package manager. The DLLs were stored in different directories. Since there are dependencies between the DLLs, NetDefGen was only able to create the copy modules after I copied all the DLLs together into one directory.