First of all i am a novice .NET programmer and I stuck in trying to fix an issue with a custom SQL Profiler tracer like the one described here - http://www.codeproject.com/Articles/20173/MS-SQL-Server-Profiler-with-NET
So, I use the TraceServer(http://technet.microsoft.com/en-us/library/Microsoft.SqlServer.Management.Trace.TraceServer.aspx) class to InitializeAsReader and immediately it throws me a
"Failed to initialize object as reader."
with an InnerException -
"Could not load file or assembly 'file:///c:\\Program Files (x86)\\Microsoft SQL Server\\100\\Tools\\Binn\\pfclnt.dll' or one of its dependencies. The system cannot find the file specified.""
Interestingly this happens only when i try connecting to a SQL Profiler 2012 and I don't face a problem with 2008R2. Also I noticed that the pfclnt.dll is present in "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn" and not inside the folder that is mentioned in the trace.
Is there a way I can ask it to load it from the right location? Why is it looking at the wrong location in the first place?
Alright, I realized that my project had references to SQL Server 2008 Assemblies especially this one - C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SqlServer.ConnectionInfoExtended.dll. I removed those references and added references to the 2012 libraries present in C:\Program Files (x86)\Microsoft SQL Server\110\SDK\Assemblies and everything works now!
This question - SQL Server file names vs versions helped me understand the weird folder names that SQL server uses to separate versions.
Related
I'm struggling to find any meaningful information on this issue so any thoughts would be greatly appreciated.
I have a SSIS 2016 package that has a Visual Basic Script Component that requires connectivity to a remote Informix database via an ADO.Net connection. The necessary project reference to the IBM.Data.Informix.dll has been added and the project builds without error. However when the package executes a runtime failure occurs:
"Could not load file or assembly 'IBM.Data.Informix.4.0.410.02, Version=4.0.410.2, Culture=neutral, PublicKeyToken=7c307b91aa13d208' or one of its dependencies. The system cannot find the file specified.":"IBM.Data.Informix.4.0.410.02, Version=4.0.410.2, Culture=neutral, PublicKeyToken=7c307b91aa13d208"
I have tried some of the suggested solutions I have come across including setting the reference property, "Copy Local = False" as well as repointing the reference to the various versions of the installed dll. File locations include the GAC, "C:\Program Files\IBM Informix Client SDK\bin..." and "C:\Program Files (x86)\IBM Informix Client SDK\bin...". Both 32 and 64 bit versions are installed and the dll files do exist in the referenced locations. All attempted solutions failed.
Any suggestions where I can go to from here?
Thanks in anticipation.
I've got a .dacpac file that's being called by MSBuild and published to a QA database for testing. This publish is failing and the error I'm getting back from them is a generic "an error has occurred" message. I was hoping I could generate the deployment script from the dacpac and walk through it to see where the problem is occurring and hopefully teach them how to do this as well.
Is there any way to point a dacpac at a specific database and have it generate the sql for updating the database without actually publishing to the database?
You can use SqlPackage.exe. Look for it on your machine in a directory with a name similar to this:
C:\Program Files (x86)\Microsoft SQL Server\130\DAC\bin
Note that it may be found in the 110, 120 or 130 folder.
If you don't have SqlPackage.exe already, you can download it from here: https://www.microsoft.com/en-us/download/details.aspx?id=53013
If you download it, be sure to look in the System Requirements section of the download page to find the dependencies SqlSysClrTypes.msi and SqlDom.msi, which must be installed as well.
Example usage:
SqlPackage.exe /a:script /SourceFile:C:\temp\mydb.dacpac /TargetConnectionString:"Data Source=myserver;Initial Catalog=mydb;Integrated Security=true" /OutputPath:C:\temp
I am trying to build a program for x64, but I keep getting the following error messages:
C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(2554,5): error MSB4216: Could not run the "GenerateResource" task because MSBuild could not create or connect to a task host with runtime "CLR4" and architecture "x64". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe" exists and can be run.
C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(2575,7): error MSB4028: The "GenerateResource" task's outputs could not be retrieved from the "FilesWritten" parameter. Object does not match target type.
MSBuild.exe exists and can be run, so I don't know why I am getting these errors.
I am using Visual Basic in Visual Studio Professional 2013 (Update 4). I am not using any DLLs, all I am creating is a standalone .exe file.
I've tried searching, both here and on Google, but cannot find anything helpful. Then again, I have a tendency to overlook things, so the answer has probably been screaming in my face for the last hour. I apologise in advance if this turns out to be the case.
Any and all help is very much appreciated.
replace
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe
by
C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe
and try.it should do some difference.this occurs because the version on msBuild.exe has changed after update4 of vs2013.check for version differences..
also i suspect you are trying to build the solution in x86 architecture.if first solution doesnt work,go to the Build tab, change the Platform target from Any CPU" to "x86" and try. hope it helps.
I just encountered this exact same error in a multiple project VB solution when trying to start a debug instance of one project. By forcing a rebuild of that one project I was able to fix the issue and start the debug instance.
I solved this problem by opening the project in Visual Studio 2017, instead of 2015
So in SSMS, the template browser has all of these preloaded templates that i personally will never use. I'd rather just clear this out so i can start my own structure, however, everytime i delete them from:
C:\Users[user]\AppData\Roaming\Microsoft\SQL Server Management Studio\11.0\Templates
and reboot SSMS, they all magically reappear. The templates that are in there are more or less worthless to me, but i would like to get out of saving query projects or quick templates to a folder and just put them in here for organization and ease. There's no settings that i can find that causes the behavior so i was wondering if anyone had an idea how to disable this feature.
Any help would be appreciated!
If you want to remove the default templates completely, we need to delete the files and folders under both of the following folders:
64-bit SQL Server:
%ProgramFiles(x86)%\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\SqlWorkbenchProjectItems\Sql
C:\Users\<user>\AppData\Roaming\Microsoft\SQL Server Management Studio\11.0\Templates\Sql\
32-bit SQL Server:
%ProgramFiles%\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\SqlWorkbenchProjectItems\Sql
C:\Users\<user>\AppData\Roaming\Microsoft\SQL Server Management Studio\11.0\Templates\Sql\
In SSMS 2008 R2 the folders are:
C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\SqlWorkbenchProjectItems\Sql
C:\Users\<user>\AppData\Roaming\Microsoft\Microsoft SQL Server\100\Tools\Shell\Templates\Sql
Instead of deleting the existing templates, I created a "z MS Shipped" folder and moved them into there, just in case.
I wonder if this is some sort of reference issue in Visual Studio Express 2013. I am building from source so none of these files should have to be registered after the fact. Upon running the type library from the bin folder in an external program as a custom command, it returns the interop.scripting.dll not found error. What could be causing this? Does it matter that some reference paths for COM files point to the obj folder and not bin (I think this is normal)?
Example references (I can't post images yet) --
C:\FNNTQuarterlyReports\SourceCode\obj\Debug\Interop.esriSystemUtility.dll
C:\Program Files\ArcGIS\DotNet\ESRI.ArcGIS.Catalog.dll
C:\FNNTQuarterlyReports\SourceCode\obj\Debug\Interop.Scripting.dll
c:\Program Files\Microsoft Visual Basic 2005 Power Packs\3.0\Microsoft.VisualBasic.PowerPacks.dll
This has been solved. Not entirely sure of the details, but I started fresh with a backup copy of the source and left the original .NET and COM references as-is. The key difference is the use of powerpacks.VS as opposed to the new 3.0, and older ESRI dlls (dating to 9.1 period). All had copy-local set to true. For some reason this build works fine... trying to modernize the references somehow messed things up, possibly due to a compatibility issue, or some other oversight. Thanks for the help.