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
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've written a large C# 4.0 App in Visual Studio 2010. Some time ago I added the CEF framework (version 43.0.0.0) in order to utilize a web-browser inside my WinForms application.
If I run my app from Visual Studio, the browser runs correctly. However, upon using ClickOnce to deploy my app, it threw the following error: "Could not load file or assembly 'CefSharp.Core.dll' or one of its dependencies. The specified module could not be found." Although all the CEF files are present in the bin\Debug folder. In fact I found a page on GitHub listing which files are required, and a careful check verifies that all are present in the executable folder.
A list of required files can be found here:
One of the points made in the above article, are that the Visual C++ Redist files are required and asks in question 6. How do I include the Visual Studio C++ 2012/2013 redistributables on the target app?
It specifically states that CefSharp version 43.0.0 and below needs VC++ Version 2012. Therefore, I downloaded vcredist_x86.exe (the 2012 version)
I created a package.xml and product.xml Bootstrapper files in the Microsoft SDKs folder. I included these as a prerequisite in Visual Studio 2010's Publish screen.
However, upon a ClickOnce deployment and an attempt to launch the CEF Web Browser, it immediately throws the exception "Could not load file or assembly 'CefSharp.Core.dll' or one of its dependencies. The specified module could not be found."
I am at a loss as to what to do, in order to get the browser to work outside of my development environment, i.e., for the End-User to successfully use.
I've followed all the steps that I've found on line, both on Stackoverflow and Github for CefSharp. What else is required to get this working?
Please help!
I'm adding this addendum in case anyone working with CefSharp has run into the same issue, namely "Could not load file or assembly 'CefSharp.Core.dll' or one of its dependencies. The specified module could not be found.". It turned out to be a ClickOnce issue. ClickOnce included all the "managed" resources, but did not include the unmanaged ones, i.e., cef.pak, cef_100_percent.pak, d3dcompiler, libcef.dll, icudtl.dat, etc.
If I right-clicked on References and attempted to browse to these resources to add them, Visual Studio complained about them being unmanaged and would not allow them to be added.
After working with the Microsoft ClickOnce and Deployment forum, it was suggested that I right-click on the project, Add > Existing Item and add them. Then set their Build Action to "Content" and Copy to Output Directory to "Copy Always."
This allowed the resources to show up in Application Files... on the Publish tab. After another ClickOnce deployment, launching the Web browser was successful. No more complaints about missing files.
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.
Well, I've been trying to make a C++ DLL in Visual Studio 2015, which took a while since I'm not very good with Visual Studio.
I need to access the .NET libraries, specifically System::Management. (Writing the code was a little harder than it needed to be due to a poor C++ implementation, but at least it has one.)
I fixed obvious errors and finally figured out I had to enable CLR in the project properties and then select the related libraries with References->Add Reference. But after all that, now it's just giving this weird error:
LNK1104: cannot open file 'MSCOREE.lib'
The compiler doesn't show red wavy lines below anything, and the error claims the line is "1" and the file is "LINK", so no help there.
I thought I probably messed up the project configuration somewhere, so I created a new project and moved the code over. The error still happened. If I turned off CLR and commented out the .NET-dependent code, the build succeeded without errors.
So I tried creating a new project from template (Visual C++ -> Win32 Console Application) and then enabling CLR before doing anything else. Then I tried again, selecting different versions of .NET framework.
Finally, I tried creating a project with template (Visual C++ -> CLR -> CLR Console Application) and building it immediately. I mean literally without doing ANYTHING ELSE. It still gave the same error!
LNK1104: cannot open file 'MSCOREE.lib'
What on earth is going on? Am I doing something wrong here, or is VS2015 just broken?
I had the same problem. Installing ".NET Framework 4.6.1 SDK" solved the problem. Pay attention to the version number, take it from your project configuration files
Check in Visual Studio installer 'C++/CLI support' for build tools of your needed version.
Try this,
Right click the project that shows 'LNK1104: cannot open file 'MSCOREE.lib'', then select Properties --> Configuration Properties --> VC++ Directories --> Library Directories --> Add both entries from below separated by semi-colon
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\x64
This is where your 'mscoree.lib' should be, check if its there before doing this otherwise you might need to install/reinstall the Microsoft SDKs
In some situations the SDK may not install the required files in the LIB folder as described in MSCoree.lib missing from WinSDK. Their solution was to execute a repair of the install. That may not work.
I have successfully ran WinSDKInterop_amd64\WinSDKInterop_amd64.msi resulting in the creation of:
C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\IA64\mscoree.lib
C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\mscoree.lib
C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\x64\mscoree.lib
Here's an interesting problem that really has me scratching my head. I have a project that's being built in TeamCity. It's been working fine until a developer added a resource file to one of the projects with some strings for another locale. He's added the .resx file under the Properties folder next to the default one. Here's the error message from the build log:
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2105, 9):
error MSB3091: Task failed because "AL.exe" was not found, or the correct
Microsoft Windows SDK is not installed. The task is looking for "AL.exe" in the "bin"
subdirectory beneath the location specified in the InstallationFolder value
of the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A.
You may be able to solve the problem by doing one of the following:
1) Install the Microsoft Windows SDK for Windows Server 2008 and .NET Framework 3.5.
2) Install Visual Studio 2008.
3) Manually set the above registry key to the correct location.
4) Pass the correct location into the "ToolPath" parameter of the task.
There are a number of things here that I can't work out.
- How come it can find AL.exe for the default .resx file but not for this new one?
- Why's it looking in a registry key that looks Vista-specific, when the build is running on Server 2003?
Any ideas?
Problem solved by installing Windows SDK for Windows Server 2008 and .NET Framework 3.5 SP1.
I don't understand how MSBuild got out of step with its tools, perhaps I never will discover the reason, but installing that SDK fixed the problem for me.
Check msbuild from x86 is used. There should be an option in TeamCity build runner.
Was VS2008 installed on the machine?
Make sure the Windows SDK is completely installed on the server. AL.exe (Assembly Linker) is included with the .NET SDK (not the runtime).
(I have the same problem on my TFS server with ClickOnce, but too lazy to fix)