CS2001 Missing AssemblyAttributes.cs when executing SSIS package deployed to the server

Question

I created SSIS packages and used the Integration Services Deployment Wizard to deploy it out to the server. I'm manually going to the Integration Services Catalog access through SQL Server 2012 and right-clicking and executing my package.

However, the package keeps failing and I'm getting the following errors when I check the execution report's messages.

They appear to be failing on data tasks where I have script components.

Assign :Error: CS2001 - Source file 'C:\Windows\TEMP.NETFramework,Version=v4.0.AssemblyAttributes.cs' could not be found, CSC, 0, 0

Assign :Error: Failed to compiled scripts contained in the package. Open the package in SSIS Designer and resolve the compilation errors.

Foch

do you have the correct .NET framework installed on the server? – Paratroops

What do you mean by the correct .NET framework? Like, the right version 4.0 vs 4.5? – Foch

Yes as in the correct version. Looking at the error it is complaining about the assemblyattributes.cs missing. – Paratroops

Gotcha. I checked and I do have .NET 4.0 installed – Foch

hmmm... could it be that the script component was not build properly? Sorry I cant be any more help without having access to the packages. – Paratroops

Answer 1

This answer is a more detailed version of UberDoodles answer.

In Windows Explorer.

1. Navigate to C:\Windows\Temp\
2. Right click the folder and select properties
3. Go to tab Security, choose Advanced
4. On the default tab Permissions, choose Change Permissions
5. For the relevant Permission entry, choose edit.
6. By default, I had 'allow' checked for Traverse folder / execute file, Create files / write data and Create folders / append data.
7. Also check 'allow' for List folder / read data and Take ownership.
8. Press OK, the window closes
9. Press Apply and confirm anything you need.

Additionally, the logged in user had already Full control, but when I changed this for the entry 'Users', it worked for me.

(based on microsoft file/folder permissions).

Embodiment

This worked for me once I added the permission for [SERVERNAME]\Users, although I'm not sure which account is actually being used for the scripts when the package runs. I assumed the SQL Server service account, but apparently not. – Gertiegertrud

This worked for me as well. after upgrade server OS to 2022 and SQL from 2016 to SQL '22 also – Gounod

Answer 2

I had the same problem today, just on SQL 2016. For me it helped to change the target server version in Visual Studio project properties from SQL Server 2012 to SQL Server 2016.

Comeaux

Painful solution, but it worked - and I guess it's the "right" way to go about it. It also means all the packages with code need to be recompiled. PITA. The other responses about adding full perm to temp is an exploit vector waiting to be pwned. – Provost

Answer 3

I was investigating the same issue, and I came across a solution here :

https://social.msdn.microsoft.com/Forums/vstudio/en-US/73e67f3a-c575-4c73-a71d-ed7a2aeabb50/csc-error-cs2001-source-file-cwindowstempnetframeworkversionv40assemblyattributescs?forum=msbuild

Basically, the account which the package runs under needs to have full permissions to the C:\Windows\Temp\ folder, so that it can create temporary classes.

It worked for me :)

Chemosmosis

Worked for me! Even though the users/settings weren't too straightforward on my pc, I had to change permissions from 'Users' instead of the user I was logged in with. How to alter permissions: msdn.microsoft.com/en-us/library/bb727008.aspx – Embodiment

Answer 4

I had the same problem. I first used Eric G. response and added the List and Read permission to the c:\windows\temp. After I got everything working I went back and removed that permission. I then redeployed my solution from Visual Studio, this time designating the deployment target as SQL Server 2014 (which was the environment I was using) using Martin's solution. I then reran the process, and it worked with the List and Read removed.

I kept it using Martin's solution, as I don't like to have special permissions granted if I don't need them.

Good Luck

Pleasant

Answer 5

[Visual Studio 2017 15.9.16]

I just restarted Visual Studio as Administrator and the issue disappeared, which confirms the permissions idea of the answers above but spared me all work.

It's not a quirk though, as per this question and its answer you need that kind of permission for several tasks, like profiling and debugging under certain conditions.

For the sake of completeness, this blog says you might incur in some security contraindication if run VS as administrator when opening third-party solutions.

Bevon

Answer 6

I was using script tasks in my workflow, I was having the same issue. Ensure that you do the build of .net code within each script task separately.

Farahfarand