I developed a dll used by a SSIS to be able to perform web api call.
This dll is registered with regasm and gacutil to be able to use it with the task script in the SSIS.
I updated the dll, I deployed it and register the new version with regasm and gacutil.
When I run the SSIS, the result still the same as the old version of the dll. So I presume that the dll still loaded in the memory.
In the server, I already stop/start the services SQL Server and SQL Server Agent but I still have the issue.
Any ideas ?
When looking into my old deployment code I always removed old version from GAC using:
(path)\bin\gacutil.exe –u assembly_name
(path)\bin\gacutil.exe –i assembly_file_name
If it is a custom component, I copied the dll to (SQLServerpath)\DTS\PipelineComponents
Related
This is Edited from the OP. This is a VB .NET 4.0 WinForms application. There is a mysql datasource involved with this project. The target CPU is set to any. Problem: When running this application on any computer that has VS 2010 installed along with the mysql connector it runs flawlessly. When installing on a virgin system(ie. No developer environment installed) but that machine does have .net framework 4.0 installed and a mysql server without the connector installed the application falls immediately. So to fix the issue I install the mysql connector MSI. This immediately fixes the issue on the client system and it runs. The problems is that as you can see below from my Installer setup that the 2 needed DLL files for MYSQL are actually included in the installation package so should not need to be installed separately. So Why is it that using that installer from the images do I need to install the mysql connector? Any Ideas? Below is a screen shot of the References the program uses and from what I believe I do not need to deploy any of those DLL files with my application other than the 2 MYSQL DLL files. So why is this failing?? Below are images showing the project references as well as the Installer Files that are being installed in the applicaiton folder. As shown in the image the 2 mysql dll files are to be put in the application folder. There is also a screen shot showing each dll's properties for in application folder.
You answered your own question.
but that machine does have .net framework 4.0 installed and a mysql server without the connector installed the application falls immediately.
You don't need to install the connector msi package, but you do need to include the two DLL files in the application's directory. Anytime you have some dependency, you need to deploy it with your application.
Edit solution quoted from my comment:
From your update it sounds like you have a version mismatch on the
assemblies, and the references are set to Specific Version = True.
Check the version number of the assemblies on your developer machine
in the output directory, and check the version you are installing on
the client system. (You can just hover over the DLL to read the
version on the ToolTip). You can try to set Specific Version to false
by right clicking your reference and selecting properties, or simply
ensure you deploy the same version of assemblies. Your program is
looking for the versions its compiled against
We have recently added AppFabric as a caching option in our project (Windows server version, not Azure cloud). The project thus now has a dependancy on Microsoft.ApplicationServer.Caching.Client.dll and .Core.dll.
Our build server is Windows 2003 and thus AppFabric cache cannot be installed onto it, thus these assemblies are not available.
Short of including the afore mentioned assemblies as explicit binaries in our SVN repository, and referencing them directly (yuck), are there any suggestions as to how to build the project?
Secondly, if we checked in the binaries, performed the build then deleted them from the output folder, is there a way to force .NET to search the %windir%\system32\AppFabric\ folder for the assemblies?
MS do not register them in the GAC...
If your application is using an assembly that can't be installed on your build server, then the solution is to upgrade your build server to Windows 2008.
I'm trying to add a .NET 4.0 .dll to the GAC. I am attempting to do this because it is published by a 3rd party company as both a 32 and 64bit .dll which I must use from different apps on different platforms in both formats.
At any rate, I am having trouble registering this dll to the GAC on a Windows Server 2008 environment.
I have tried copying gacutil.exe (and supporting file) found at "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools" on my local machine to the "C:\Windows\Microsoft.NET\Framework\v4.0.30319" folder on the target production server per the suggestions found here.
I then tried copying them to "C:\Windows\Microsoft.NET\Framework64\v4.0.30319".
Running from both locations indicated successful installation. And indeed, the registration appears successful:
C:\Windows\Microsoft.NET\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\Microsoft.NET\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
However, running a console app that refers to the (64bit) version of the dll errors out with the following message:
System.IO.FileNotFoundException: Could
not load file or assembly
'ChilkatDotNet4.dll' or one of its
dependencies. The specified module
could not be found. File name:
'ChilkatDotNet4.dll'
So, I have now manually created the following GAC entries using mkdir and copy from a command prompt (which may or may not actually work. I have no clue what is so special about gacutil.exe):
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll (using the 64bit version of the dll)
C:\Windows\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
After each "install" of the dll, I tested and received the same error. Any ideas welcome!
EDIT: the GAC issue above may not actually be the culprit. Turns out, even when I create a brand new Console App project and add the .dll directly (so that it lives in the bin), I still can't run it on the sever. Also, I've noted that Console apps are created targeting the .NET 4.0 Client Profile rather than the .NET Framework 4. When I try to run it targeting the client profile, it appears that none of the System.Web* libraries are available. However, I tried running a very simple test app targeting both and neither would run on the server while referencing the bad .dll.
Is there a special kind of install that was to occur to run .NET 4.0 Console Apps?
For anyone else who may have trouble with this in the future. It was not a generalized problem with the way I was registering the dll to the GAC or how I was referring to it from my projects.
ChilkatDotNet4.dll (and the other versions I'm sure) was built in Visual C++. So, the server it is being deployed to has to have the Visual C++ Runtime installed for the appropriate processor architecture.
For 2010 (.NET 4.0):
x86
x64
If you're running an x86 app on a 64-bit platform. Make sure to mark the application pool with "Enable 32-bit applications" = true.
I'm trying to reference a COM dll in visual studio by using the Browse tab and selecting the DLL. I noticed that if the DLL is registered on the system with regsvr32 I can reference it, but if it's not registered I receive an error selecting the dll file "A reference to 'file.DLL' could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component."
We would like to keep the DLL not registered, so that we have less configuration needed on other development machines and on the development environments.
Is it too much to ask?
Thanks!
you need to register dll. you can set registration in your setup project or create a batch file for all these type of processes.
Note: Don't forget to unregister dll on uninstallation.
You'll need to register the dll because otherwise it would not be able to find the type library.
Adding the dll afterwards as a reference to you project will create the interop.XXXXmethod.dll assembly.
You need to have the COM server registered, period. You could take some measures to automate the process though and to unregister the COM server when it is not needed.
The same applies to daily builds. If you build a COM server and a .NET based client during the build you have to register the server prior to building the client. And you better unregister it as soon as the client is built. Adding these steps to the build sequence is not a problem at all.
You might be able to use Registration Free Com
I am installing an application on a client machine. The application is throwing an exception that I am logging that states "Class Not Registered". This an app written in Visual Studio 2005 using VB.NET. The dll dependencies of my .exe are located in the same folder as the .exe. What class is this talking about and how can I resolve this issue?
Does the application use any COM components? If so, make sure that they get registered properly on the client machine. You can either have the setup do this for you (if you have created a setup), or use the regsvr32 utility.
Based on the comments, I would say that you will need to install SQL Server on the client machine. I am no SQL Server expert, but I would guess it would be sufficient with the Client Components.
Try commenting out most/all of the code in the project (or create a hello,world setup) to isolate whether it's one of your 4 dependencies or something else entirely.