I have developed an application using C# (Visual Studio) which runs without issue on my Windows 10 development PC. However, when I copy the application to its intended target PC and run it (Server 2012 R2), I get an exception informing me that a file or assembly could not be loaded: Microsoft.SqlServer.ConnectionInfo, Version=13.100.0.0.
If I copy version 13 of the dll to the program directory of the target PC and run the app, I then get an exception informing me that it cannot find version 14 of the dll. Copying version 14 to the target then give me the original exception, and so on.
I have references to all the required dlls in the application, namely:
Microsoft.SqlServer.ConnectionInfo.dll (the one which is giving me
the issue). Microsoft.SqlServer.Management.Sdk.Sfc.dll
Microsoft.SqlServer.Smo.dll Microsoft.SqlServer.SqlClrProvider.dll
Microsoft.SqlServer.SqlEnum.dll Microsoft.Web.Administration.dll
All are set as: specific version = false.
All of the necessary frameworks are installed on the server. Additionally, the following is also installed on the server, which the program interacts with:
• ColdFusion
• SQL Server 2012 (and 2008 but this instance is not used by the program)
The .exe is installed via an installer and that installation includes the necessary dlls, which are installed in the same directory as the exe.
Full permissions are available on the directory, and the program itself has the highest access level.
The connection string is selectable by the user and defaults to the correct one, depending on where the program is installed.
Does anyone have any ideas which may help me to resolve this conflict?
Thanking everyone in advance.
Regards,
Ken.
ADDITIONAL INFORMATION
The version number of Microsoft.SqlServer.ConnectionInfo.dll shown within Visual Studio is 13.100.0.0. I copied the DLL from the path shown in properties, to the program directory. Guess what? When I ran the program an exception informed me that it could not find version 14.100.0.0!
This is the version of the same DLL as shown on the file's Properties page: 13.0.16106.4.
SMO is always installed in the GAC, so it doesn't matter what files you copy to your /bin folder. GAC'd assemblies override local ones.
You have referenced the SQL 2016 version of SMO. So you must either install that on your target server, or build you project against the version of SMO already present on the target server.
See
https://learn.microsoft.com/en-us/sql/relational-databases/server-management-objects-smo/files-and-version-numbers
Note that because of the hassles with loading and deploying SMO, and SMO's really old API style, it's often better to have your app perform SQL Server administration with just TSQL and System.Data.SqlClient.
[RESOLVED]
Dumbassary was afoot.
I removed all the references from the Visual Studio project, re-added them and it worked.
The issue was caused by a DLL reference which was pointing to the program's installation directory and not to C:\Program Files (x86)\Microsoft SQL Server\130\SDK\Assemblies. As the Properties box was not fully expanded, I failed to notice it.
Hopefully, someone else can benefit from my experience.
Thank you for your comment David.
Related
I have a perfectly working windows forms C# .NET 4 application that uses a SQLite3 database file to store data and display forms.
When I deploy my app on any machine other then the dev machine, I get an exception thrown and it's message is "Could not load assembly System.Data.SQLite.dll or one of its dependencies. The specified module could not be found."
The System.Data.SQLite.dll reference in the project is set to Copy Local = True. Also, I tried manually loading the assembly with Assembly.LoadFile. The dll is placed in the output directory. I also tried setting the platform target to Any CPU as well as x86, no difference. All machines I am working with are 32-bit. What is the issue here? Why is my application trying to load the assembly and can't find it?
Thanks!
I had the same problem after publishing my program to a separate computer. Installing Microsoft Visual C++ 2010 Redistributable Package (x86) on the separate computer fixed the problem.
Note: the separate computer already had Microsoft Visual C++ 2010 Redistributable Package (x64) installed, the x86 version was needed.
'System.Data.SQLite.dll" requires "msvcr100.dll" which is one of it's Dependencies. This will be available only if you installed latest "Microsoft Visual C++ Redistributable" or any other product which internally provides this.
For example, VS2010 will install C++ Redistributable by default. Thats the reason your application doesnot works in some machine but works in others.
You could try pasting the "msvcr100.dll" in your application bin folder and distribute if you dont want to install VC++ 2010 Redist in all the PC's.
Some of the System.Data.Sqlite.dll modules depend on the "Microsoft Visual C++ 2012 Redistributable Package" .
You can find required dependencies on the official download page : http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki
The answers already given didn't solve my problem. I tried to deploy to a VMware server. The solution that did help where given here: http://sqlite.1065341.n5.nabble.com/System-Data-SQLite-Deployment-Mystery-td71752.html Two methods are described there.
When i install this sqlite-netFx45-setup-bundle-x86-2012-1.0.88.0.exe, my app is able to find the right dll.
The second method is to add the dll to de app.exe.config in the debug or release dir. If you edit this file directly, there is a change VC will overwrite the file.
My main problem was that i installed the sqlite package manually. I didn't use NuGet, because i'm behind a proxy. If you do use Nuget, the information in the app.exe.config will be provided automatically.
Using NuGet behind a proxy is described here: NuGet Behind Proxy
I have a very simple custom assembly written in C# using VS2017 that is being deployed to Microsoft SQL Server Reporting Services Version 13.0.4435.0 running with SQL Server 2016 (SP1-CU3) (KB4019916) on a Windows 10 box.
Below is the C# code for this "Hello World" custom assembly:
Namespace MyCustomAssembly
{
public class HellowWorldClass
{
public static string HellowWorld()
{
return "Hello World!";
}
}
}
Microsoft describes a step-by-step process for deploying a Custom Assembly:
https://learn.microsoft.com/en-us/sql/reporting-services/custom-assemblies/deploying-a-custom-assembly
Following the steps in the process, the first thing that I discovered is that the Report Designer default directory was different. After trying various folders, the destination that worked was the following:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\SSRS
After depositing the custom assembly DLL in this directory, the report preview worked as expected. This provided verification that the expression in the report textbox was defined correctly.
In accordance with the process, to deploy the custom assembly on the server the DLL should be placed in the following destination, adjusted for the specific SSRS version:
C:\Program Files\Microsoft SQL Server\MSRS13.MSSQLSERVER\Reporting Services\ReportServer\bin
The process then describes steps that extend the permissions of the custom assembly but this simple example should not require that. Execution permission should be sufficient. Therefore modification of rssrvpolicy.config should be unnecessary.
When I attempt to deploy the report to the serer by right clicking on the report in the Solution Explorer of VS2017 and selecting "Deploy", I get the following message (and only this text):
The definition of the report '/HelloWorldReport' is invalid.
If I remove the textbox containing the reference to the HelloWorld function in the custom assembly, the report deploys successfully to the server. So while there is no further information available in the message about why the report is invalid, it appears to be associated with the custom assembly on the server.
Here is what I have tried:
In spite of it not being required according to the process, I went ahead and edited rssrvpolicy.config to grant "FullTrust" to the assembly. Restarted the server.
I read that SSRS is based on .NET 3.5 (I built the assembly with 4.5.1) and that libraries needed to be built on .NET 3.5 to work. The custom assembly build was changed to use .NET 3.5.
Ensured that .NET 3.5 (and dependencies .NET 3.0 and 2.0) were installed on the server box. This was a long shot.
Reviewed various other tutorials and videos about the creation and deployment of custom assemblies. All seem to indicate that all that is necessary in this case is the placement of the DLL in the proper directory on the server.
Copied the custom assembly DLL in various other directories on the server. The thought was that if the VS2017 was in error maybe the server directory was also in error.
I looked into assembly security. Went through the signing process for the DLL. Used gacutil to install the custom assembly into the GAC.
In another desperate effort, I installed VS2017 community on the server and created a simple report and custom assembly on the server. Just as before, the VS2017 report preview presented itself correctly and the server deployment failed.
None of the above efforts worked.
I can share the RDL file or other material that might help identify the problem but I don't believe that the issue is with the report definition because the report will deploy if the references to the functions within the custom assembly are removed. And I don't believe that the issue is with the custom assembly because the preview works within the VS2017 environment. Is has to be something with the server but the error message is very opaque.
This is the first time that I have reached out to the SO community. I'm generally reserved and somewhat hesitant. Yet the experience of others has proven valuable to get by past development challenges and I am grateful. But I am really stumped this time. No one seems to have had this exact experience that I can find and I have searched exhaustively. I have little concern if the solution turns out to be a simple oversight or some basic ignorance that is worthy of ridicule. I just need a solution with what seems to be a non-problem for others.
Refer the following URL for solution:
https://developercommunity.visualstudio.com/content/problem/574712/rdl-deploy-error-vs-2017-ssrs-2017.html
Copy custom DLL to this folder C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\PrivateAssemblies on the developer machine.
One solution that worked is to use Report Manager to add the report rather than deploy from Visual Studio.
Just had the same problem as is described here.
For me the problem is that the DLL must be in two folders on the machine from where the report is being deployed:
For the DLL to work during development:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7
\IDE\CommonExtensions\Microsoft\SSRS
And to be able to deploy the report:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7
\IDE\PrivateAssemblies
Of course on the server the DLL must also be in the ReportServer\Bin folder
Also, I have seen posts about assembly having to be .NET 4.0, but this is not the case for me..... mine is 3.5
I'm developing an app that execute another app and I received this error:
the program can't start because MSVCR100.dll is missing from your
computer
with my C# app, can I fix this problem copying this .dll into windows/system32 folder?
Or exists another method to do this?
This links below point to the proper downloads for the MSVCRT100 installer. This is likely what you want your customers to run before installing your app. This will properly install the MSVCRT DLLs in the proper directory such that all applications can use it.
Microsoft Visual C++ 2010 Redistributable Package (x86) (probably what you need for 32-bit and 64-bit os)
Microsoft Visual C++ 2010 Redistributable Package (x64) (Only if your app itself is 64-bit)
If you actually want to install the MSVCRT100 DLLs through a merge module within your own MSI - you can link your MSI to the MSMs that are located in the x86 version your "c:\program files\common files\merge modules" directory" (Assuming you have Visual Studio 2010 installed).
C:\Program Files (x86)\Common Files\Merge Modules>dir *CRT*.msm
Volume in drive C has no label.
Volume Serial Number is 60A4-1718
Directory of C:\Program Files (x86)\Common Files\Merge Modules
04/22/2011 01:18 PM 584,192 Microsoft_VC100_CRT_x64.msm
04/22/2011 01:41 PM 571,904 Microsoft_VC100_CRT_x86.msm <-- This is likely the MSM you want if your app is 32-bit.
04/22/2011 01:14 PM 847,360 Microsoft_VC100_DebugCRT_x64.msm
04/22/2011 01:39 PM 801,792 Microsoft_VC100_DebugCRT_x86.msm
Two other alternatives:
Instead of copying MSVCRT100.dll into a system directory, copy it into the directory of the EXE app you are trying to launch that depends on this DLL. This isn't recommended, but won't run the risk of breaking other apps.
Another alternative. If you actually have the source code to the EXE that you are trying to launch, you can completely bypass all of this "install msvcrt100.dll" noise by just statically linking to it. In visual studio, it's the option in the project's propery dialog under C/C++ (under the Code Generation tab). Change "runtime library" from "Multi-threaded Dll" to just "Multi-threaded". This adds the /MT compiler switch.
Whatever program you're trying to start has to be properly installed first. Msvcr100.dll is one of the DLLs that need to be deployed for programs written in C or C++ with VS2010. It is simple with a Setup and Deployment project or by building the program with the /MT option. Contact the program owner for support.
what is missing is the Visual C++ runtime.
are you starting a C++ application from your C# code? if so, make sure the proper runtime is available on the client machines.
You should be able to fix this by copying it and registering it (with command line: regsvr32 "DLLNAME") or you can ship it with your executable and it should work
WARNING: Please consult the following article before including the file with your software... http://msdn.microsoft.com/en-us/library/ms235299.aspx
I take no responsibility for your actions
I believe that I am dealing with some DLL hell.
I have a reference to Microsoft.TeamFoundations.VersionControl.Client in my application and 'copy local' is set to true. The application runs as expected on my development machine.
When I deploy this application I get an exception when trying to execute Microsoft.TeamFoundations.VersionControl.Client.DownloadFile()
Method not found: 'System.IO.Stream Microsoft.TeamFoundation.VersionControl.Client.Item.DownloadFile()'.
The version that gets deployed to my bin directory is version 9.0.3. The method exists. I noticed that a previous version of this dll does live in
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies
How come my application does not appear to be using the assembly that I referenced within my solution and ends up in bin? How can I force this to happen?
Thanks!
I'm not sure if this is it, when I was trying to use TFS 2008, I had to target the x86 processor instead of Any CPU in the project settings. Without doing that, I was finding wierdness when my app deployed to other peoples machines.
Also, I deploy a number of dll's with my app, maybe you've missed deploying something that VersionControl.Client.dll depends on, and it's trying to use another dll of which it's getting the wrong version. I distribute the following (not sure if they're all needed, but you could try distributing more to see if that solved it):
Microsoft.Build.Framework.dll
Microsoft.TeamFoundation.Build.Client.dll
Microsoft.TeamFoundation.Client.dll
Microsoft.TeamFoundation.Collaboration.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.Common.Library.dll
Microsoft.TeamFoundation.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
Microsoft.TeamFoundation.VersionControl.Common.dll
Microsoft.TeamFoundation.VersionControl.Controls.dll
Microsoft.TeamFoundation.WorkItemTracking.Controls.dll
Microsoft.VisualStudio.TeamFoundation.Client.dll
Microsoft.VisualStudio.TeamFoundation.dll
Microsoft.VisualStudio.TeamFoundation.WorkItemTracking.dll
It appears from this link Microsoft.TeamFoundation.VersionControl.Client.Item.DownloadFile() is missing that there are other (and presumably safer) way to do this with other methods.
The application insisted on referencing these dlls from the GAC. I ended up installing VS 2010 on the development environment and referencing the Microsoft.TeamFoundation dlls from the GAC. VS 2010 installed version 10 of the Team Foundation dlls into the development GAC.
HI
I have creted an exe by c++ using visualstudio. I have creted a com componet which discover all the instances of sqlserver on particular machine.now in c++ program using visualstudio i write main() and consume the com component.
Now it should worrk on my both workstations which are w2k3 machines.And when i try to run the same on w2k8 machine i got the error as
the application has failed to start because the side by side configauration is incorrect and for details see the application event error log
i open the application error log and found the error as
Activation context generation failed for "E:\SQLDiscovery.exe". Dependent Assembly Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50608.0" could not be found. Please use sxstrace.exe for detailed diagnosis.
How to resolve this one plz help me
You have to install the VC8 Runtime on W2k8. This is due to Windows Side by Side configuration.
When you build and EXE, a special file is generated called "manifest", this manifest file describe the version of the C runtime library that is needed by your application in order to run correctly.
The Manifest is then embedded into your exe/dll ( if you actually opened the .dll/exe using notepad and scrolled to the end, you will see it in xml format), you cal also use mt.exe ( manifest tool ) to view the manifest inside any executable.
When you move your application to W2k8, you have to ensure the dependent CRT is installed ( unless you statically link your app with CRT).
You can resolve this issue by either one of these
1- Install VC8 Debug CRT
2- Build you app as statically linked
Check out this blog as well
http://detritus.blogs.com/lycangeek/2006/08/diagnosis_of_wi.html
It contains useful information about how to debug winsxs issues.
Hope this helps
The problem is that the EXE requires the debug CRT DLLs and they are not present on the 2008 machine. How you fix this depends on what you want/need to do.
If you want to use the debug CRT, either link statically to the CRT (removing the need to have the DLLs on the 2008 machine) or create a directory called "Microsoft.VC80.DebugCRT" in the same directory as the EXE, and put the necessary DLLs and the debug CRT manifest file there.
The debug CRT is not redistributable, AFAIK there is no way to "install the debug CRT" other than installing all of Visual Studio.
If you don't actually need the debug CRT, link with the release version. Again, you'll need to choose between the static LIB and the DLL version. The good news is that the release CRT is redistributable, check your Visual Studio install directory for vcredist_x86.exe.
Don't ship debug builds. Build it in release, and then put that on your target machine.
If you use the CRT (you do) then you need to install the CRT redistributables. You need to install (on the target machine) the ones which match the version & SP of the compiler you used to build the application. It's very simple & standard practice
Here's a link where you can get the redists for VC8: link
And here's a link for the redists for VC8 SP1: link text
Just google "vc8 redist" or whichever version you are using and you will find your way.
Don't statically link your app just to avoid having to install the redists.