I need to migrate several DTS packages as noted above. They're actually running fine when I run them via dtexec.exe on the command-line. But if I try to install and run them via SQL Server Agent - as they were previously and as such are supposed to - I get the bogus error message, that
C:\Windows\Temp\.NETFramework,Version=v4.0.AssemblyAttributes.vb
...couldn't be accessed. I say bogus because this (generated?) file is actually there and should be accessible since I'm running all of this logged into SQL Server via Windows Authentication as local administrator.
(Update: I should explicitly mention that I've tried creating and running these jobs off the SQL Server Integration Services as well as directly off the file system. Both methods end up with the same result described above.)
After trying to read up on the matter I got the impression that you migrate such packages correctly by installing Visual Studio / Data Tools / Integration Services, loading the DTS packages in there, inspecting and fixing any errors - i.e. rebuild the whole thing in the new IDE. So I set out to do that, and got a bunch of the following error messages for VisualBasic scripts within the DTS package:
The binary code for the script is not found. Please open the script in the designer (...)
I did that, and was notified about a missing type:
BC30002 - Type 'Microsoft.SqlServer.Dts.Pipeline.SSISScriptComponentEntryPointAttribute' is not defined. (...)
This seems really weird, because I'm able to open the type's sources in question in Visual Studio without problems.
Why does this happen and what can I do about this? Why do I need to bother with all of this if the DTS packages run fine with dtexec.exe on the command-line?
Exact server versions:
Thanks for everybody's suggestions and sorry for the long period of silence. What I finally did to come by this problem (after trying out lots of other stuff) was suggested in an answer to a related SO question.
It sounds pretty crude - Open the .dtsx file in a text editor and remove any section defining the target framework version manually:
<PropertyGroup>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
</PropertyGroup>
If I understand it correctly, this is simply a reference to the version of the targeted .NET framework. If it is removed, once you open and save it in the newer Visual Studio 2019, it will fill in it's own defaults:
<PropertyGroup>
(...)
<TargetFrameworkVersion>v4.7</TargetFrameworkVersion>
(...)
</PropertyGroup>
The (...) denote that Visual Studio 2019 will add other properties which were not there before.
You'd think this should be possible to do via the project configuration, but it my case, it was not.