How can I add reference to an external assembly from within a script task and deploy the package to a server along with the newly added external assembly?
If this is in reference to your other recent question, then the only proper way to get the correct version of a Word DLL on the server where you want to deploy to is to install the proper product onto the server. Most DLL's (especially from products like Microsoft Office) are not redistributable (meaning you are not legally allowed to copy them from machine to machine without the underlying product installed). If a DLL from Microsoft is redistributable, then there will be a document accompanying the DLL that tells which DLL's are allowed to be copied from machine to machine and what the correct process for doing so is.
If this is not in reference to that question, then can you provide more detail about what it is you are trying to do so that we can help you more.
Assuming you are using SSIS 2008 (it was a bit different for SSIS 2005) -
the referenced assembly needs to be installed into GAC (Global Assembly Cache)
on target machine where you run the package.
Related
I have some custom control flow and data flow tasks that are not showing up in the SSIS Toolbox. When I open a package in SSDT containing the custom tasks I get several errors loading the package.
Error loading MyModuleTemplate1.dtsx: Cannot create a task from XML for task "__ECT Fetch Configuration", type "MyEncryptedConfiguration, MyCustomTasks, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2bdffe791d57af79" due to error 0x80070057 "The parameter is incorrect.".
I've followed Russ' and Matt's replies from the following post http://social.msdn.microsoft.com/Forums/sqlserver/en-US/5fdf9243-7e38-401e-bf4a-9251738877f9/how-to-browse-the-installed-custom-task-in-sql-server-2012-ssis-ie-custom-ssis-control-flow-task, however, the tasks still don't show.
I'm using SQL Server 2012 x64 with SSDT on Windows Server 2008 R2 x64. I have verified that the tasks are in the GAC and that the assemblies are in the appropriate SQL Server\110\DTS directories. The assemblies have been compiled as 32-bit since I kept getting a warning about targeting Any CPU while referencing 32-bit assemblies (the SQL reference assemblies).
I'm able execute the packages with the custom tasks, on the target server successfully through command line. Additionally, these tasks work fine on my development machine. I can see the tasks in the SSIS Toolbox and can open packages with the tasks without issue. My dev machine is nearly identical to the target machine except that I have full installation of Visual Studio 2010.
Am I missing something?
This problem is the result of WiX installer not properly installing the custom tasks. Below is what I did to verify this.
For test purposes I created an empty custom task and manually deployed it to the target server by copying the files and the DTS\Tasks directory. This worked so I added the .cs file of one of the tasks that was throwing errors, to the test custom task and re-deployed. I was able to see both tasks. After cleaning the solution with the original custom tasks, I manually deployed the original custom task to the target server, like the test custom tasks and was able see the tasks in the SSIS toolbox. I then uninstalled the custom tasks and deployed them to the target server using a WiX installer -- the problem resurfaced. So the problem is with the installer. My previous attempts at manually installing the custom tasks failed because I was using the assemblies installed from the WiX installer, although I don't know why.
I am writing a portable application that connects to both a firebird database and a mysql database. I am writing the application in Delphi 2010, and using dbExpress components to connect to both databases. SQLconnection component uses dbxmys.dll and libmysql.dll for the mysql database, and dbxfb.dll and fbclient.dll for the firebird database.
On my development computer I had to move the dll files into /windows/system/. I think this is because of the system paths, in order to find the correct files and connect. I tried this on another client machine, and the software could not connect because the dll files were not found. Because this is a portable application I do not want to include a sub directory of the application directory to include the dll files, however I do not think the a client machine can run the applicaiton without having mySQL and Firebird installed and the pathing set correctly.
Is there a better way to do this? I have concidered making a sub directory and forcing my application to look there, (since firebird and mySQL can be installed anywhere) if they were included I would know for sure were they were at on any computer my app is launched from. But I don't really want to take this approach.
What are my options as far as direct db connection, or solving the dll requirement problem, I am not an experienced software developer. Thanks in advance.
Update:
The DLLs are now in the same directory with the exe, and the application launches fine. I Still do not want to use any dlls. I have found a few components that do not require dlls, but they also require payment, finding another free option would be ideal.
What you can do is to store the .dll within the main .exe as zipped resources, then expand them in a local folder (local "Application data" for instance), and execute the library from there. Therefore, you do not need to put files in the system path (probably with administrator rights), nor change the path itself.
As a result, you do not need to copy the .dll with the .exe, and if the .dll are already available, your application will use them. The .exe folder won't be "polluted" by the library files, and your software could be still self-installing: if you copy the .exe in another computer, you still have the .dll within it, ready to be installed in an hidden local folder.
This is for instance how our SynProject tool use Hunspell libraries for spell checking. See this SO answer.
I'm trying to create some Crystal Reports via SSIS which works wonderfully when it can find the DLLs, but not so much when it can't.
I've gone into the package to add the references, but the problem is when the package is running from SQL Agent it can't find the references since they aren't in that drive path.
Is it possible to put the DLL files in separate locations that can be accessed independently and have the path to the DLLs be stored in a variable and then referenced either programmatically or have the path defined dynamically?
Thanks
All DLL references used in SSIS need to be registered with the GAC.
You have a couple of different options to do that, check out my previous answer for the how: How do I use COM reference within SSIS package?
You could try copying the DLLs to the SQL Server binary folder (in my case "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\binn").
I had this problem calling a .Net library that uses HtmlUnit. The NuGet version I'm using doesn't have a Strong Name, and so can't be GACed, but that worked for me.
Is it possible to deploy a custom assembly to a location other than the Reporting Service's bin directory?
I know that deploying to the GAC would likely work, but I'm more curious about using an arbitrary directory on the server dedicated to deploying custom assemblies.
I'm not opposed to altering any rs config files, if a possible solution involves that.
According to MSDN, you must deploy to the \bin directory or install in the GAC (MSDN link.) Those are your only options.
The Microsoft SQL Server forum has an identical discussion going on. A Microsoft support engineer gave the same answer: it can't be done.
I have a .NET application which uses an accdb file (MS Access 2007 format) as its database. To install this app on another machine I need to install the Access engine on that machine. Microsoft has this file: AccessDatabaseEngine.exe which includes the engine, but when extracted during installation, runs another .msi installer.
As you can guess, since this msi is run during the installation of another msi (my app's installer) the Access engine setup fails with error 1500: "Another installation is in progress. Finish that one before continuing this one..."
I found the Runtime for Access 2007 as well, and it does install the engine, but the Runtime package is again an msi installer which means I'm still having the same problem.
Any ideas to include the engine in my app's installer?
You probably want to have a look at this article: Adding Programs to Access 2007 Deployment Packages
The Access Developer Extensions offer a basic but functional installer that can take care of the general deployment scenarios.
The best think would be to build your own msi pack including needed access files. You could use a product like VERITAS Wininstall. You have this "Discover" method that allows you to build a fully operationial .msi file by (1) taking 2 snapshots of your system (one before the installation, one after) then (2) creating the .msi file corresponding to the installation process.
Anyway, I'd advise you to have multiple packs, one for Access, that can be installed with a "for all users" option when the computer joins your company's domain, one for your app. By doing so you will be able to distribute new versions of your app without redistributing Access, which takes a few mega of space as well as a few minutes of user's most precious time).
Sio if Microsoft already delivers an Access Runtime msi package, just keep it 'as is' and distribute it automatically on your network when a new machine joins the domain.
I wouldn't recommend WinInstall, we have it in my office and we have to keep calling them in to package stuff for us as it's so finiky to use. Some things they haven't been able to package at all. WISE Studio is better or a free alternative is AppDeploy whihc I have heard great things about.
I found this software called "Bootstrapper Manifest Generator" or BMG. It helps create a prerequisite package using an MSI or EXE installer file, and adds it to VS2008 Prerequisites dialog box in Setup and Deployment projects. Although it's not that user friendly, it does the job. It's on MSDN: code.msdn.microsoft.com/bmg
Thought it's good to save others from going through all the trouble.