I have a solution in Visual Studio 2013, where among the others I have also a Database project. This project contains some .sql written in T-SQL.
IntelliSence and Parse (SQL (on visual studio menu) > Parse) do not work. I have gone through this Troubleshooting guide and many question on SO, but nothing worked.
As I understand is something in project setting that I need to configure or some leftovers I need to clean.
Any suggestions ?
In brief
IntelliSence is enable
SQL CMD is Disabled
In SQL Server Explorer there is an entry (localdb)\ProjectsV12 containing my DB.
Other solutions opened on the same instance of visual studio work fine
ReSharper is installed but is not the issue (I also tried without it)
Note:
The solution (the one that has issues) was created in a previous version of Visual Studio.
Update 15/12/2015
After some digging I found out that the issue may has something to do with the .v12.suo file (which is located alongside with .sln file and is hidden). Copping this file from a similar solution (one that IntelliSence works) eliminates the problem.
Another workaround that it may help, is to go to the "Database Project" properties (right click on the project in Solution Explorer and then select Properties), on the Debug tab and press Restore Default in "Target Connection String". In my case this just changes the Initial Catalog= value to Database and like "magic" IntelliSence works again! (in some cases it may need to restart the Visual Studio)
After this even if I restore (using Edit) the "Target Connection String" to the previous values the IntelliSence continues to work.
Related
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.
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.
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.
I'm trying to do a simple call to a database stored procedure from a C# application.
I'm following a guide like, e.g., this one or this one.
Both of these have the same basic steps.
Add a LINQ to SQL .dbml item to my project
Connect to a database in Server Explorer
Drag a stored procedure from the Server Explorer onto my .dbml designer window
But step 3 doesn't work. I have my stored procedure and my designer window, but I can't drag the sproc. I don't get a plus sign, or a "not allowed" sign. It's just a non-dragable object.
I can't find another way to add my sproc to the .dbml file. And I can't find anyone else who has had this problem. Every source simply says to drag it over.
What could I be doing wrong here?
Screenshot:
Turns out the solution was that I had the wrong version of a .dll for Visual Studio.
I noticed I was getting exceptions when performing actions in the Server Explorer. Googling the exceptions led to this question which points to this dll
C:\Program Files (x86)\Common Files\microsoft shared\Visual Database Tools\dsref80.dll
as the issue.
I replaced it with the corresponding copy from one of my teammates and it now works fine.
I had also installed VS 11 Beta and the designer was working fine until I uninstalled it. I had to delete the DLL manually at the above location and repair the installation by finding Visual Studio 2010 in Programs and Features and selecting Uninstall/Change and then Repair. The installer will replace the DLL file that was deleted with the correct version.
For anyone that can drag the sproc, but sees no result (the sproc simply does not show up in the functions pane): make sure that the sproc only returns datatypes that L2S understands. For example you can not return a geography field.
Editing .dbml files with a designer surface requires the LINQ to SQL tools which are not installed by default as part of any of the workloads of Visual Studio 2017. It can be installed by selecting the "LINQ to SQL tools" item under the "Code Tools" category in the "Individual Components" tab of the Visual Studio installer.
I am getting trouble to use Build solution in Visual Studio.
I was building data cube and I needed to use Build solution to finalize my project.
However, I couldn't find Build solution from the Build menu.
For example ....
http://cfile7.uf.tistory.com/image/18493D524E2CF5A31F8B61
It should be like this then I can choose build solution option
However, when I tried on my laptop...
http://cfile8.uf.tistory.com/image/16493D524E2CF5A21E9D27
I was unable to find these options...
I am not really sure about my mistakes....
My data was built by SQL Server 2008 R2 and I was using Visual Studio (which came with SQL Server)
Does anybody know solution to this problem?
From the second screenshot that you posted, it looks like you don't have a solution open, just the project that was contained in the solution. A Visual Studio solution file is usually a .sln file, and if you open it up in Notepad you'll see that it's just an XML file which describes project(s) it contains (the actual project files are different, the solution just makes reference to the project filenames). Make sure you get the .sln file to your laptop and open that, not the project file.
Right click on the solution or Project node which is on the Solution-Explorer. There should be Build menu item.
Or may be the Visual Studio coming with SQL 2008 R2 doesn't have that functionality?