I have:
SSIS/.dtsx package with a script task in SSIS that I added references to. It works fine locally (assuming the .dlls are in the GAC).
When depolying on the server it failes (assuming the .dlls are NOT references in the GAC) and I can not add them.
The SSIS package is stored in Integration Services on the SQL server in the Stored Packages - MSDB
The job runs on a schedule
I do not have access or the ability to add .dlls or add items to the GAC on the server.
What I need to do is find a way to include the .dll in the script task inside the SSIS package so that the References point to those .dlls instead of any in the GAC.
I searched quite a bit and could not find a way to do this. Is it even possible? If so what/how do I do it?
Locally it does work, in server it cannot find a required reference. what referenced dll is missing? you know it?
Once you know what dll you need, get a copy of it and, even if you cannot install it on the server GAC, you can deploy it in the same folder you deploy your executable.
At runtime, your executable will first try to load the dll from the same folder, if not found, it will try searching in GAC.
Related
I have built software that is capable of exporting DTSX package automatically. This package among other objects has also a ScriptTask (C#). All are compiled and run just fine.
Now the new requirement is to call a class in that ScriptTask, which exists inside an external DLL we have built, so other applications can consume the same code. So we implemented a loading mechanism of the DLL, using reflection.
Assembly clientLib = Assembly.LoadFrom("C:\\......\\mylibrary.dll");
Type licenseCheckType = clientLib.GetType("myclass");
object instance = Activator.CreateInstance(licenseCheckType);
The code is running just fine, but there are several permission issues during deployment.
Running the package from DataTools, the package fails because cannot find the file. If I executed the DataTools as administrator is working. Still, I don't get it, as a user I should be able to browse the file.
Running the package from SQLAgent(this is important), the package fails. If I set the SQL Agent service user with "Local System" or "Administrator" user the is working.
I am looking for a way to find how I can make it work with a simple user by adding permissions to that path if necessary, but still, keep failing. I tried to set a simple domain user as SQLAgent Service account and give Full Control as a start to the directory without success.
Error: Exception has been thrown by the target of an invocation.
Implementing the loading mechanism from GAC, is working, but I would like to explore the other way as the DLL in my case, this DLL is referencing a LiteDb file in the system directory, and it would be nice to have them all together.
Assembly clientLib = Assembly.Loadm("mylibrary");
Type licenseCheckType = clientLib.GetType("myclass");
object instance = Activator.CreateInstance(licenseCheckType);
As a summary:
Using the GAC
UI will reference the local DLL because exist in bin folder
SSIS will reference the GAC DLL because of loading from GAC, which references a db file from local folder
Using the Local (problematic)
UI will reference the local DLL because exist in bin folder
SSIS will reference the local DLL because of loading from local folder, which references a db file from local folder
am create a desktop application using wpf. am installd newtonsoft.json(using package manager) for json parsing. after am successfully build and run my application.
then iam copy the appliction.exe from project source > bin > debug to my Destop. then am attempt to run exe from Desktop, but i got an error message
like this
could not load file or assembly 'newtonsoft.json' ..... system cannot find
the path
what is the issue? any missing
The exe needs to be able to link to the dll when you run it. That's why it works in your debug folder (the newtonsoft dll is there if you look), while it's presumably not in your desktop.
You can either:
1) Make sure the dll is included with the exe (copy it to your desktop, for example). If you distribute the exe in a zip file, just include the dll. If you use an installer, make sure it also installs the dll to the same folder.
OR
2) ILMerge the DLL directly into your exe - this means the exe contains the entire DLL and will always be able to find it. There are NuGet packages that can do this for you autonatically. Try adding "MSBuild.ILMerge.Task" via NuGet, and then build your project again.
(There are other solutions but they're generally terrible, like PATH, so I'm not going to explain how they work).
Personally, I'd usually recommend the former - just include the DLL. Look inside folders where you have software on your PC (e.g. most folders in Program Files) - you'll see that's how it's usually done, with DLLs installed as separate files. ILMerge can get messy if you don't know what you're doing and you start doing weird things with your DLLs.
How can i have 'Create Assembly' reference the build output path.
I have an SQL CLR that references a web service.
I have an entry in the PostDeployment script
CREATE ASSEMBLY TestWebServiceClientXML from N'\\TestServer2012\clrdeploy\Test\TestWebServiceClient.XmlSerializers.dll' WITH permission_set = EXTERNAL_ACCESS
Currently this works fine. I build the TestWebServiceClient separately manually, that builds the dll and XMLSerializer dll to a share that SQL can see. When i then publish the database project with the CLR in that references this, the PostDeployment scripts uses the XMLSerializers dll I've just built from the share.
How can I get this scenario to work with a build server? All the build outputs, including the XMLSerializers dll will go to a single build output path on the build server and when the post deployment script runs it will create an assembly from an old version on the share '\TestServer2012\clrdeploy\Test\' as this is hard coded, not the version just built.
Eventually I want this to run within Release Management. Anyone done this before?
Using SQLCMD variables, have the build server pass the build folder's path to SqlPackage.exe as a SQLCMD variable. Then modify your post deployment script to look something like this:
CREATE ASSEMBLY TestWebServiceClientXML from N'$(BuildFolder)\clrdeploy\Test\TestWebServiceClient.XmlSerializers.dll' WITH permission_set = EXTERNAL_ACCESS
The DLL files under _bin_deployableAssemblies belongs to SQL Compact....
apparently do not get installed via Nuget (neither with Microsoft.SqlServer.Compact 4.0.8854 or EntityFramework.SqlServerCompact 6.1.1). Exclude the _bin_deployableAssemblies from Git and when a co-worker cloned the project only "shadow" copies of the dll files were present. The automatic build copy process from _bin_deployableAssemblies to bin failed for him.
Don't have a history of my Nuget installations but I suspect either a package setup up this dll or I did it somehow in the solution.
Read Michael Dudley's blog about pushing SQL Compact with projects. Along with a Nuget setup that tries to address 4.0.0.1 assemblies.
Is there a reason why these dll are missing when cloning the project? Why the shadow copies then?
Is there a reason why these dll are missing when cloning the project?
Perhaps because executable files and bin directories aren't usually considered source files under version control.
Why the shadow copies then?
The "shadow" copies are presumably the items in the project file, i.e. the DLLs are identified in the project file
I'm using a mysql .NET Connector library (Mysql.Data) in my project. As far as I understand it, I only need to use the mysqldata.dll which is in the assemblies folder after the connector is installed. I'm going to be using the program on a computer that has .NET 2.0 but doesn't have the connector.
How do I add the .dll file to a project such that the dll is used internally - I hope that makes sense. If the program calls out to .NET to find it, (as it does) - the whole thing fails and errors out.
In Solution Explorer, under your project, expand References, select the MySql.Data assembly, view the Properties for the assembly, and change Copy Local to True. Now when you compile the project, MySql.Data.dll will be output to the bin directory.
(You will not embed one assembly into another. Instead, you deploy the MySql.Data.dll along with everything else in your build output which is required. This is simply known as adding a reference ... I don't think you really wanted to embed it.)