Binary code in the script is not found

May 21, 2013 at 5:03 PM
Edited May 21, 2013 at 5:03 PM
Hi all,

I am trying to use the new EzScript component. My C# code looks like this:
        EzScript BuildNaturalKey = new EzScript(DataFlowTask1);
        BuildNaturalKey.ScriptLanguage = "CSharp";
        BuildNaturalKey.ReadOnlyVars = "User::NaturalKey";
        BuildNaturalKey.AttachTo(LoggingInfo);
        Console.Write("Script Input - " + BuildNaturalKey.InputCount.ToString());
        BuildNaturalKey.LinkAllInputsToOutputs();
        BuildNaturalKey.InitNewScript();
        BuildNaturalKey.PutSourceFile("main.cs", codeString);
       BuildNaturalKey.InsertOutputColumn("NaturalKey");
        BuildNaturalKey.SetOutputColumnDataTypeProperties("NaturalKey", DataType.DT_WSTR , 700, 0, 0, 0);
        BuildNaturalKey.Build();
Everything works fine, code runs, package is generated, but when I open it in BIDS I get the error "Binary code for the scriptis not found." When I open the script editor, the code I placed in main.cs is there, and when I simply close the window and hit okay, the script compiles.

The key difference, of course, is now the BinaryCode element of the script task's XML in the package has the binary code in it, when the original generated package is blank.

I thought the Build() command generated the BinaryCode? I see the thing in there with the BinaryCodeIndexer, but I have no how idea how to use this, and well, you guys aren't the best about documentation : )
Aug 9, 2013 at 9:17 PM
I'm not sure if you were ever able to solve this yourself, but after a bunch of digging I just got this working for a project I am building. The Build() method should generate and attach the binary code as long as your project compiles successfully. The problem is that you won't know it failed to compile when you run your project to create your package.

In your case (which was the same problem I was having), you need to make sure you call the InitNewScript() method AFTER you add your output column(s). The InitNewScript method is responsible for creating the BufferWrapper.cs and ComponentWrapper.cs files. The BufferWrapper.cs defines the Input and Output class (usually called Input0Buffer) which creates the properties which map to your input and output columns for the script component.

Since you hadn't added your output column yet, when you called the method it didn't create the necessary properties in the Input0Buffer class. When the Build() method is called, it fails trying to compile main.cs because you are referencing a property that doesn't exist.

The reason this is hard to track down is as soon as you click the "Edit Script" button in the designer, it regenerates the BufferWrapper.cs file based upon the input and output columns defined in the Script Component which includes your dynamically added output column. Therefore everything looks good and when you save/close the editor the binaries build correctly and everything is good. If you open the generated .DTSX file before editing it in the designer you can see the source code that was generated and will see that it does not have the properties for the output columns.

Your code becomes:
        EzScript BuildNaturalKey = new EzScript(DataFlowTask1);
        BuildNaturalKey.ScriptLanguage = "CSharp";
        BuildNaturalKey.ReadOnlyVars = "User::NaturalKey";
        BuildNaturalKey.AttachTo(LoggingInfo);
        Console.Write("Script Input - " + BuildNaturalKey.InputCount.ToString());
        BuildNaturalKey.LinkAllInputsToOutputs();

        // Add your output column(s) first
        BuildNaturalKey.InsertOutputColumn("NaturalKey");
        BuildNaturalKey.SetOutputColumnDataTypeProperties("NaturalKey", DataType.DT_WSTR , 700, 0, 0, 0);

        BuildNaturalKey.InitNewScript(); // This generates the BufferWrapper.cs, ComponentWrapper.cs, and main.cs

        // make sure this still gets called AFTER InitNewScript, you are overwriting the previously created main.cs
        BuildNaturalKey.PutSourceFile("main.cs", codeString);  
       
        BuildNaturalKey.Build();
I believe some fairly simple modifications to the EzScript code can make this process a lot less painful.

Hope that helps.

Ryan
Aug 10, 2013 at 2:34 AM
That worked great, glad you tracked this down.

I actually just ended up creating my own custom component (a lot easier than I thought it'd be) since it was going to get a lot of re-use and I wanted to store the code somewhere else besides a config value in an EzAPI project.

If I have time next week I'll work on integrating these changes into my EzScript.cs file and submitting a commit to the codebase.