1

I thought this would be simple, but I guess not. Here is what is happening. I create a new package and add a script task to it. I open up the script task and edit the script (C# 2010). In the solution explorer, I right click the project name (ST_xxxxxx). I select "Add->Existing Item". In the file explorer, I navigate to my documents folder and select (not double click) my "test.cs" which is just an empty class. At the bottom right of the file explorer window, next to the Add button, I click the down arrow and select "Add as Link". To test, I select "Build->Build ST_xxxxx". Build succeeds. I save, then close the script task VS editor. Then I click ok on the script task editor window. A "Script Error" window appears. "Scripts contained in the package have compilation errors". If I do save it, The error on the task says "Binary code for the script is not found"

Any ideas how to get around this?

I can go through that same process and select "Add" instead of "Add as Link" and it works fine. But that creates a copy of the file and has to be updated manually. I want to link to my common cs files that I use all over and not have to update them.

Any help would be appreciated.

Rob Shelton
  • 21
  • 2
  • Also, this problem happens with 2012 SQL server data tools. I've tried the same thing in 2008 and it works fine with Add as link. – Rob Shelton May 14 '17 at 15:02
  • Huh, I don't know why it gives you that option as the added code needs to be serialized into the resulting Script Task – billinkc May 14 '17 at 18:08
  • Not sure either. If it worked, and depending on how it worked, it seems like a good option to avoid the whole copy/paste approach or having the server admin install a new DLL onto the production machine each time I add something new. If you have other approaches, I'm all ears. – Rob Shelton May 15 '17 at 20:32
  • Found the solution. Just drop the dlls into a sharedrive accessible by the dev environment and production servers. Then add this code (in next comment) to the script task before (or after) the Main (entry point) function. Then add the same dll(s) as a reference to the project. Works like a charm. – Rob Shelton May 17 '17 at 22:08
  • static ScriptMain() { AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve); } static System.Reflection.Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args) { if (args.Name.Contains("ssisHelper")) { string path = @"c:\temp\"; return System.Reflection.Assembly.LoadFile(System.IO.Path.Combine(path, "ssisHelper.dll")); } return null; } – Rob Shelton May 17 '17 at 22:11
  • https://blogs.msdn.microsoft.com/dbrowne/2014/06/25/how-to-load-an-assembly-in-a-ssis-script-task-that-isnt-in-the-gac/ – Rob Shelton May 17 '17 at 22:12

1 Answers1

1

Found the solution. Just drop the dlls into a sharedrive accessible by the dev environment and production servers. Then add this code to the script task before (or after) the Main (entry point) function. Then add the same dll(s) as a reference to the project. Works like a charm.

static ScriptMain() { AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve); } static System.Reflection.Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args) { if (args.Name.Contains("ssisHelper")) { string path = @"c:\temp\"; return System.Reflection.Assembly.LoadFile(System.IO.Path.Combine(path, "ssisHelper.dll")); } return null; }

https://blogs.msdn.microsoft.com/dbrowne/2014/06/25/how-to-load-an-assembly-in-a-ssis-script-task-that-isnt-in-the-gac/

Rob Shelton
  • 21
  • 2