0

I am writing a custom SSIS component that works fine when run from within Visual Studio; however, it fails when run using dtexec.exe or dtexecui.exe.

The failure occurs in the PreExecute method when I am building up a mapping from column names to LineageIDs. This is where I am confused, as I look at things in the debugger all I am doing is passing the value I get from var foo = output.OutputColumnCollection[i].LineageID to bufferManager.FindColumnByLineageID(output.Buffer, foo)

At this point I get an exception thrown from FindColumnByLineageID saying,

System.ArgumentException was unhandled by user code Message=Value does not fall within the expected range.
Source=Microsoft.SqlServer.DTSPipelineWrap StackTrace: InnerException:

I am at a loss. The code runs fine in BIDS the logic at this point seems OK, there really is nothing to do wrong, I am just passing a value from SSIS back to SSIS. My feeling is that there is some setup or configuration that is getting messed up but I don't have any idea what it would be at this point. Any guesses would be most appreciated.

Thanks!

Ukko
  • 2,236
  • 2
  • 21
  • 33

3 Answers3

0

Is your Visual Studio machine a 64-bit environment? You might want to try running the 32-bit version of DTExec.exe, i.e. the one in Program Files (x86).

There's a reasonable number of issues that arise when trying to run a package using the 64-bit version.

Geoff
  • 8,551
  • 1
  • 43
  • 50
  • I am running all the instances under 64 bits. I tried setting the use 32 bit flag in Visual Studio and it still worked. I looked through your links and I don't think we are doing anything like they mentioned. Thanks for the suggestion! – Ukko Apr 16 '12 at 16:32
  • Out of interest, did you try running the 32-bit version of dtexec anyway? I think either should work regardless of the instance architecture, and it would be interesting to hear if this makes no difference (or otherwise). – Geoff Apr 16 '12 at 17:08
  • Yep, 32 and 64 worked the same. I solved this today and I will write up the answer this evening once I get the time. – Ukko Apr 17 '12 at 18:59
  • Glad to hear you got it working - I'm sure it will be useful to have the answer here for future searchers. – Geoff Apr 17 '12 at 19:06
0

have you registered the custom component?

Custom SSIS components, such as a custom task or custom transformation, are not moved over with the deployment utility. You must manually move and register the components to enable the SSIS packages to access them.

Diego
  • 34,802
  • 21
  • 91
  • 134
  • I see the same behavior on my development box. The exception is coming from inside my code so the custom component is getting pulled in. Now there might be some configuration magic I am missing, but I don't know what that would be off hand. – Ukko Apr 16 '12 at 15:57
0

I promised to follow up on this with an answer over a year ago, sorry about the wait. The distance of time has made some of the details fade but basically I was problems because the components were actually wired up differently in the two environments.

When running in BIDS there are invisible components added to the component graph that are not present in the command line case. I suspect this is to provide support for the GUI updates and the ability to attache viewers and all.

I was trying to be clever and pull some information out of that graph and was just getting lucky because of the extra component hiding there in the BIDS case. (It felt like one of those bugs where something is allocated on the stack when it should have been on the heap and your fate depends on when that bit of the stack will get stepped on.) Once I fixed the bad assumptions I was making about the component graph then this resolved itself.

Ukko
  • 2,236
  • 2
  • 21
  • 33