In SSIS EnvDTE and other dependencies not found

[Dick C.]

Hi

When I start up Visual Studio for SSIS package development and add a
VB.Net Script task to the package the messages below show up and The
script can't be compiled. This happens before I add any text to the
script.

The dependency 'EnvDTE' could not be found
The dependency 'Microsoft.SQLServer.VSAHosting' could not be found
The dependency 'Microsoft.SQLServer.DTSRuntimeWrap' could not be found
The dependency 'Microsoft.SQLServer.PipelineHost' could not be found
The dependency 'Microsoft.SQLServer.msxml6_interop' could not be found
The dependency 'Microsoft.SQLServer.SqlTDiagM' could not be found
The dependency 'Microsoft.SQLServer.VSAHostingDT' could not be found

I completely uninstalled Visual Studio 2005, the .Net 2.0 Framework, SQL
Server 2005 and then reinstalled all of them but I still get the same
message.

I used GacUtil and it shows these are in the GAC but I am completely at
a loss as to what to try next.

Any help would be appreciated.

-Dick

*** Sent via Developersdex http://www.developersdex.com ***

[David P.]

It appears that the Visual Studio for Applications host does not know
where to find these assemblies in their native locations.

I had similar dependency warnings in a Scripting Task, so I placed
copies of these DLL's directly into the .NET Framework 2.0 directory (in
my case, the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 folder).
Once I did this, the dependency warnings went away.

A couple of the DLL's were in the GAC, but the host couldn't find them
there either.

Having multiple copies of the DLL's on your machine is not an elegant
solution, but in this case it does appear to solve the problem.

David

[DickChristoph]

Hi David

I will give that a try

In the case of

Microsoft.SQLServer.VSAHostingDT

I could not find this anywhere on my system. I looked on our Production
server as Well which doesn't have this issue but the
Microsoft.SQLServer.VSAHostingDT was nowhere to be found

Thanks

-Dick Christoph
"David P." <granit...@gmail.com> wrote in message
news:O1%23KPBE5...@TK2MSFTNGP04.phx.gbl...

[David P.]

The file can most likely be found in the GAC (Global Assembly Cache).
The physical files in the GAC are hidden from you when using the Windows
search feature.

I was able to get to the physical files in the GAC through the DOS
command shell. Open a command shell window and run the following
command from the root folder of the drive:

dir /s Microsoft.SQLServer.VSAHostingDT.dll

This is able to pierce the veil that has been placed over the GAC and
will give you the path to the file. Then, still from the command shell
window, copy the file from it's location into the .NET Framework
directory.

[DickChristoph]

Hi David

Well Yes I could find that File on my Home PC (where I don't have the
problem). I will have to check at work.

It was in
C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SqlServer.VSAHostingDT\9.0.242.0__89845dcd8080cc91

All this seems rather surgical, but I just about ready to start over with a
new machine at work.

Earlier you said

>I had similar dependency warnings in a Scripting Task, so I placed
>copies of these DLL's directly into the .NET Framework 2.0 directory (in
>my case, the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 folder).
>Once I did this, the dependency warnings went away.

How do you know which folder to put it in. I have that same folder on my
home machine but I also have
C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727

and
C:\WINDOWS\Microsoft.NET\Framework\v3.0

-Dick

"David P." <granit...@gmail.com> wrote in message

news:%23aNvfOM...@TK2MSFTNGP05.phx.gbl...

[David P.]

Hi Dick,

>> How do you know which folder to put it in.

I had recently read an article about adding custom .NET assemblies to
SSIS and it said to place those assemblies in the .NET Framework 2.0
directory. Since SSIS could find custom DLL's there, I figured I would
try putting the ones that SSIS couldn't find elsewhere in there as well.

Obviously, this is a workaround and not a fix, but since it solved the
problem for me I thought I'd share it.