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.
This answer is a more detailed version of UberDoodles answer.
In Windows Explorer.
Navigate to C:\Windows\Temp\
Right click the folder and select properties
Go to tab Security, choose Advanced
On the default tab Permissions, choose Change Permissions
For the relevant Permission entry, choose edit.
By default, I had 'allow' checked for Traverse folder / execute file, Create files / write data and Create folders / append data.
Also check 'allow' for List folder / read data and Take ownership.
Press OK, the window closes
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).
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.
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 :)
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
[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.
Related
I have designed a SSIS project and deployed it to SQL server and also created the job to run on daily basis but its giving me this error when executing this as job (doesnt give any error within VS):
There is this CLSid in this error message but there is no application associated to it in
--> Component Services -> Computers -> My Computer -> DCOM Config
But this CLSid is registered inside registry editor
About this particular task on which this error is occurring: This is a script task which is modifying and deleting the un-wanted rows from the excel file in which I am trying to write SQL table data.
Script task code looks like this:
I have been working for hours now trying to fix this problem but no success. Kindly guide me how can I fix this issue. If any other information is required related to this project, please let me know....
Doing Excel automation in a SQL Server agent job is totally unsupported and probably won't work.
To have even a ghost of a chance of making this work you'll need to run a real desktop session on the server and automate Excel in that. Excel expects a real user to be logged in with a full profile. And Excel has failure conditions where it displays a popup window, which you'll need to be able to access via remote desktop.
You can read and write Excel files on a server with the OpenXML SDK, without actually having to run Excel. There's also a wrapper library called ClosedXML which you may find easier to use than using OpenXML directly.
tl;dr;
You need to install Office (Excel) on the server AND ensure that you install it in a manner that mirrors the SQL Agent's expected bit-edness. Default for Agent is going to be 64bit, default for Office is still 32 :(
Error guessing
You have a script task that uses the Office interop libraries to delete some rows (2 through 11?) out of a spreadsheet.
You have Office installed on your machine and therefore you have the libraries installed. Excel still has COM based "stuff" in it, thus the interop and errors shrieking about the CLSid, registry, etc but that's likely just secondary errors because there is no base "application is not installed" exception to be thrown.
If Office is installed, then ensure your agent execution model matches the version of Office. If 32 bit Excel is already installed, don't potentially break everyone else's stuff by uninstalling and reinstalling as 64 bit, just got the Advanced section of the SQL Agent Job Step and check the 32bit box.
Once all that's done, then if you're still getting errors but new ones, then the existing comments mentioning permissions may come into play - it depends on where the Excel document actually exists (on the computer where SQL agent can access vs on the computer where it cannot vs networked drive)
Good luck in not finding people on the sanctions lists.
I've seen this question asked several times but never with a satisfacory answer. I have read through all the posts I can related to this and tried as much as I possibly can.
I have an SSIS package that loops thru a network folder of Excel files, I won't explain what it does inseide the loop container as that is not relevant.
I refernce the folder via a UNC \servername\folder
The package works fine from within Visual Studio.
I deployed the package to the Integration Services Catalogs on the
server
After I deploy, I connect to the server from my local pc via SSMS and then I execute it from SSMS via "Integration Services Catalogs"... Execute - This fails.
However If I remote desktop onto the SQL Server box, then start SSMS, connect to the SQL Server using my own credentials and execute the package using exactly the same method as above it works fine.
When I look in the logs of the failed attempts I see a warning that "The For Each File enumerator is empty". I'm not sure if this is telling the full story as, if I rename the network folder, I get the same message, (I expected to see an error that the folder was not found) - this may or may not be relevant.
I've sketched up a quick overview of what works and what doesn't
NOTE The "script execution" method is just a t-sql script for running these packages. This is the method I will use eventually but at the moment I'm focusing on the simple right-click execute method as this essentially does the same thing.
Since I did this I have tried a few more things...
I've tried accessing the folder as a UNC, a mapped drive and also UNC using IP address instead of server name.
I recreated the issue on our development server so I could change
service accounts etc.
I tried the default accounts on both SSIS and SQL Agent services.
I tried changing these to domain accounts and network service accounts.
I get the package to log the folder name which is and expression - this always looks correct. I do the same with the user name which always shows me as the exection user.
I can change most things as I can test on the development server with the excpetion of testing with a domain admin account so any suggestions would be greatly appreciated.
Running SSMS 18.6 causes the program to launch, hang, and then crash. There is no error message given, the program simply terminates before any action is taken and nothing is connected.
I've uninstalled and deleted all files for SSMS, Visual Studio, and SQL Complete.
I tried the 18.6 and 18.5.1 versions of SSMS to no avail.
From https://dba.stackexchange.com/questions/237086/sql-server-management-studio-18-wont-open-only-splash-screen-pops-up/237087#237087 :
I have tried copying the Interop.8.0.dll file from privateassemblies into public. No effect. The line in the config file mentioned here is already commented out in the recent release of SSMS.
From Sql Server Management Studio closes immediately after startup :
I have tried renaming or deleting the package file listed here and removed the relevant registry key. This causes SSMS not to open at all and Windows to issue an alert sound. No other effect.
From https://social.msdn.microsoft.com/Forums/silverlight/en-US/9d0e2459-eb74-46e8-a983-05ae2ba18977/ssms-crashes-on-startup?forum=sqltools :
I tried to repair .NET framework. No effect.
I was only able to install and successfully connect on SSMS version 17.9.1
I can provide Event Viewer details if anyone is willing to help me troubleshoot. I have a .NET Runtime error and two application errors- one is event name CLR20r3 and the other is APPCRASH. Happy to provide more information if needed.
While I can't speak to the exact reason it happened, I found a solution. Whatever the issue was, I discovered it was user specific and limited to my machine. Other users were able to access SSMS as normal on my machine as was I on theirs.
I happened to remember that the AppData folder exists and is just hidden, so I used an administrator account to copy that from a working user and rewrite the files in both of mine that were not used in some background process. This allowed me to once again access SSMS both as my regular user and with my elevated administrator account.
I had this same issue (it happened all of a sudden perhaps due to a windows update). I also tried all the other solutions listed above, but the only thing that worked for me was to uninstall and then reinstall version 7.9.1 like the original poster recommended.
In my case I only have 1 user on the computer, so the other user accounts being able to access was not applicable.
I am tearing my hair out because I was working on some SQL scripts and I executed them to ALTER stored procedure, however when I came in this morning I have lost all my work, it was showing the previous day's script. Somehow it didn't save even though I watched it Execute Successfully Completed!.
Now I thought that using Microsoft SQL Server Management Studio v17.7 there will be an auto recovery temp folder with SQL files somewhere, and from looking online its states to go here; C:\Users[User]\Documents\SQL Server Management Studio\Backup Files\Solution1\ and you will see Autorecovery.sql files lots of them.
However this is completely empty, and I got no idea where clever Microsoft has moved this new location too or removed it all together. I went to settings in my SQL studio under Tools->Options->Environment->AutoRecover and both are ticked for "Save AutoRecover Info every 5 minutes" and "keep autorecover info for 7 days". Which tells me it is somewhere on my PC.
I then thought that I might have lost my work and though it would be a good idea to test this scenario on some new scripts and guess what the folder path still shows empty whilst using MSSMS so I got no idea how to utilise this auto recovery feature for the future.
Any ideas.
Try searching in visual studio directories if you have it installed :
C:\Users\<your_user>\Documents\Visual Studio <your_version_visual_studio>\Backup Files\Solution1
SSMS 2017 seems to just keep the recovery files in %TEMP%\ (with name ~vsXXXX.sql)
I have realised the only way to make sure you are safe is to have a folder specified with all your scripts stored there.
This way the autosave only works when you have saved the file prior not unsaved files, so it will be a case of Save + Execute.
I have lost my work for now, but this is why people learn from there mistakes.
Just provisioned a new server running IIS and Server 2012 and SQL Server 2012. I also installed SQL Server Management Studio tool so I can quickly inspect databases without the need to open a remote connection.
When I browse an ASP.NET sites remotely, I get a Just-in-time debgugger exception dialog when an error is encountered in addition to the yellow screen. The dialog stays up on the server and piles up unless I RDP and manually close all the dialog boxes.
The only way to disable this is by removing Visual Studio Shell 2010 (integrated) using the control panel. The side effect is that I can no longer use SSMS.
Most of the available solutions are outdated or don't work. The registry settings are no longer applicable and most articles concerning this issue are old. Microsoft's official documentation is a rat's nest of broken links. Moreover, many users are confusing IE's script debugging dialog with this issue. Although they are related and similar, this specific issue is tied to Visual Studio's runtime environment.
Any ideas?
ASIDE: I can't believe Microsoft has this "feature" on a product that is installed on a production server. I am just floored by the incompetence of a multi-billion dollar corporation. I've seen my question asked since at least since 2005 with no official solution that works. I just have to ask one last time for sanity checking. I want to make sure I'm not the one who is "thick" in the head here.
To disable Just-In-Time debugging by editing the registry
In the Start menu, click Run.
In the Run dialog box, type regedit, then click OK.
In the Registry Editor window, locate and delete the follow registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger
If your computer is running a 64-bit operating system, delete the following registry keys also:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\WindowsNT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger
Take care not to accidentally delete or change any other registry keys.
Instead of deleting it, you can also just (temporarily) rename the AeDebug key for the bitness of your choice to something else, e.g. AeDebug-disable!
For server 2012, IIS, and SSMS 2014 we tried all three registry three deletions and those did not work.
What did work was old school renaming the JIT Debug executable.
Renamed these files.
C:\WINDOWS\system32\vsjitdebugger.exe
C:\Windows\SysWOW64\vsjitdebugger.exe
Renamed this folder
C:\Program Files\Common Files\Microsoft Shared\VS7Debug
As a follow-up to nfox's answer, I've created a registry file that you can simple use instead of searching manually through regedit.exe.
1.) Copy this script to your clipboard:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
"Debugger"=-
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"DbgManagedDebugger"=-
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug]
"Debugger"=-
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework]
"DbgManagedDebugger"=-
2.) Save it to a file with the .reg extension:
E.g. to a file named
C:\Users\<user name>\Desktop\DisableJit.reg
3.) Double click the file
After confirming the appearing message box, the keys are getting deleted.
5.) Alternatively: Download file
If this is too much effort, you can download the registry file from here:
disable-the-just-in-time-debugger-windows-64-bit.reg
disable-the-just-in-time-debugger-windows-64-bit.zip (As a ZIP)
Download and then double-click it.
This tip was simply taken from the MSDN article "Just-In-Time Debugging in Visual Studio".
The syntax on how to delete registry keys via a .reg file was taken from the MSDN KB article "How to add, modify, or delete registry subkeys and values by using a .reg file".
You should be able to disable Jist-In-Time debugging using the Debug options dialog inside Visual Studio. The registry keys are also well documented here.
See:
http://msdn.microsoft.com/en-us/library/5hs4b7a6.aspx
Aside: I think it's not a wise thing to install a management studio on a production server. This is what management workstations are for. Remote connections from a management station can be pre-configured and stored so that it doesn't take much effort. That way you can keep your production environment clean.