2

I've created a custom component for SSIS by developing a 32bit class library(let's call it CustomComponent.dll). I'm developing in VS2015, targeting SQL Server 2017. This is fine all works as it should, i.e I can see the component in Visual Studio by doing the following steps:

  • Copied the CustomComponent.dll to "C:\Program Files (x86)\Microsoft SQL Server\140\DTS\PipelineComponents"
  • Added the class library to the gac using "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\gacutil.exe" -i CustomComponent.dll

The issue I have is that the custom component now has to be a 64 bit dll as there are references to 3rd party lib's which are 64 bit (these are also added to the gac, the 32 bit versions were also added). I've done the following:

  • Removed the previous addition to the gac "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\gacutil.exe" -u CustomComponent
  • Removed the CustomComponent.dll at "C:\Program Files (x86)\Microsoft SQL Server\140\DTS\PipelineComponents"
  • Used the gacutil under the x64 folder "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\gacutil.exe" -i CustomComponent.dll
  • Added the CustomComponent.dll to "C:\Program Files\Microsoft SQL Server\140\DTS\PipelineComponents"

But I can't see the component in VS.

  • The above didn't work. I tried also copying the dll to "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\gacutil.exe" still no luck.

Any idea how to make this work to be able to view the component in the 64 bit dll? Perhaps a link that shows a walk through or an approach to try?

This link shows a simple component. But if it were compiled to the equivalent 64bit dll targeting SQL 2017, I have the same problem:

Hadi
  • 36,233
  • 13
  • 65
  • 124
user3316669
  • 79
  • 1
  • 7

1 Answers1

0

You need to add the 32-bit version since Visual Studio is a 32-bit application.

As I know, GAC support adding both versions and has a separate directory for each one (GAC_64,GAC_MSIL ...). You should add both components and only change the Run64bitRuntime property to execute the package in 64-bit mode.

If you are executing the package outside of Visual Studio you can refer to the following link for more information:

Hadi
  • 36,233
  • 13
  • 65
  • 124
  • The issue is that the 3rd party lib's, which has the functionality that the component will use no longer support 32 bit libs all updates/new functionality are added to the 64 bit libs. I'm aware that you can run the dtsx via either of ```C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DtExec.exe``` or ```C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DtExec.exe``` But for edits/make changes on the Data Flow we need to be able to see the components. At the moment the package isn't opening as the components do not exist in the Data Flow tab. – user3316669 Mar 05 '22 at 10:53
  • 1
    @user3316669 If it is possible, try to add both files even if the 32-bit is not the latest version. But be aware this will change the behavior of the package when it is executed in a 32-bit environment. – Hadi Mar 06 '22 at 10:55
  • Hi, just an update here. Adding both allows me to view the components in the designer. I run with ```Run64bitRuntime``` True. The Path variable is pointing to the 32bit location of the 3rd party libs. Pointing to the 64bit location of the 3rd party libs the components aren’t available in the designer. So executing via Visual Studio its not hitting the 64bit 3rd party libs. However on the sever, using the 64bit Dtexec the package runs from the command line and runs against the 64bit version of the libs. Path is pointing to 3rd party 64bit libs. Not being able to do it in VS is a pain. – user3316669 Mar 08 '22 at 11:42
  • @user3316669 This is because Visual Studio is a 32-bit application. I think this is the best that can be done – Hadi Mar 08 '22 at 12:59