I have reference a custom assembly in an ssis script task. The script task apparently works correctly but the assembly (first tested with a console program) doesn't work anymore.
The assembly is supposed to transform a text file to a csv file for further import. Once loaded in the script task the function referenced does create an empty file. Logging did not bring any addtionnal info.
Currently the assembly is strongly named, signed, in the GAC as well as in the DTS\SDK folder of MSSQL server.
Any idea ?
Actually the error was in my own assembly. So to summarize the correct and easy way to include and use an assembly file in a ssis script task is :
Compile the assembly with the correct framework version (in my case 3.5)
Sign the assembly
Put the assembly in the GAC
Reference the assembly within the script task and add an "imports" directive
Actually putting the assembly in the DTS\bin folder did not produce any difference.
This is why I don't usually like using custom assemblies in SSIS. In this case, I would write a jig (exe) to call the assembly and change SSIS to call my exe. In the jig (exe) I would wrap the call to the assembly in a try/catch block. I would trace the incoming parameters and log any errors to a text file or to the system Event Log. Usually, this approach gives me enough insight into the real problem (bad param, permission problem, weird data, etc) and a good way to recreate the problem and verify a solution.
Related
I have a vb.net application I'm looking to be able to distribute in the near future.
I'm not the original architect and the previous developer referenced a handful of .dll's that are under a GPL license.
All of the software that includes these dll's are freely available online, so my customer can go download and install them if they need that functionality. So I don't have to distribute the DLLs.
Currently they are referenced under the "Reference" part of the project file.
My question is, how do I resolve these dll's in a way similar to how the "references" dons it, but at runtime.
My plan is to search the registry for the location of these dll's and reference that location, but given the file location of the .dll, how do I "pull" that code into my project.
Thanks
You may try this
Search for Dll on specified path for dll
Use reflection to load assembly or dll into you code at runtime
Create runtime object from the loaded dll
Call required functionality from the dll
Reflection is the key solution to your problem that you may use to plugin new functionality into your project without distributing the dlls
This is the only solution that works
http://mylifeandsql.com/2018/03/26/replication-readpast-error/
also you can just start your migration with the following command
Sql(#"SET TRANSACTION ISOLATION LEVEL READ COMMITTED");
This will replicate dll changes like adding new column to a replicated table
You will also find that the column is automatically added to replicated articles > columns
No need to create a new snapshot nor set the sync to re-initialization ☺
Thanks
I need to make some exe file to load my DLL at startup...
What is the easiest way to do it?
I need this exactly, no any injectors or starters.
I though about adding one more code section into exe, rewriting to there entry point logic and placing DLL loading code, then NOPing original entry point and calling my custom made entry point function. Will this work?
Are there any other easer ways?
I also thinking about changing one of system dll name in hex editor to name of my DLL. Will this work? If my dll then load that replaced system dll?
Any thoughts?
Adding it to the PE's import table should be enough. Woodman's lists a few tools which can do it:
http://www.woodmann.com/collaborative/tools/index.php/Category:Import_Editors
My DTF project contains some embedded resources and I would like to access the same in the CustomAction.
I tried the following code in the Custom Action method
// Gets the current assembly.
Assembly Asm = Assembly.GetExecutingAssembly();
// Resources are named using a fully qualified name.
Stream strm = Asm.GetManifestResourceStream(Asm.GetName().Name + "." + Name);
However this doesnt work as Asm always refers to the Wix Setup assembly and not the custom action dll which contains the resources
Why not use Assembly.GetAssembly(typeof(CustomAction));, to get the assembly that contains your custom action?
To be honest, I'm not sure this scenario is possible. I mean, there might be no option (or no easy option) to get the custom action executing assembly and extract the resources out of it.
Instead of this, I would try to re-design the solution and move resources to the Binary table in MSI package. Thus, you'll still have embedded resources, but not in CA DLL, but in the MSI package itself. The DTF.chm help file contains a sample how to extract files from Binary table - it's a matter of a couple of lines of code.
I disassemled a game's DLL and want to insert some code.
I need asm code to call another DLL in the current directory(I'm on Windows).
The background is, that I want to be able to execute custom code in my DLL,
but I can't load the DLL. So my idea was to load the DLL via modified game DLL.
There may be a function in the game which gives me the current directory path the DLL's are but I think I won't find it.
The calls you are looking for are LoadLibrary, which will search in a selection of places including the current directory for the DLL and then load it, then GetProcAddress.
If the DLL makes any other Win32 calls it is probably already linked against kernel32.dll, so that's all you need to do.
It is arguable as to whether modifying the DLL or using DLL injection is faster in terms of how long it takes to write the code since you're going to have to reverse engineer anyway, however, one advantage of pure DLL injection is that all existing code remains unmodified in terms of the installation, making these modifications easier to undo should the user wish to "unpatch" whatever you are doing.
Microsoft Detours comes with setdll.exe and withdll.exe, those utilities will let you start an exe with a custom dll file.
I have a project that uses log4net and works fine on the developer machines. When we build, a step in our build scripts calls the AssemblyInfo task to set version numbers and dates, etc. But the AssemblyInfo file also loses the line:
[assembly: XmlConfigurator(Watch = true)]
Is there any way to have the AssemblyInfo task not overwrite that line, or conversely, to have the AssemblyInfo task re-insert that line into the file (along with the appropriate using statement?
You can actually put the log4net [assembly: ...] line in any file that will be compiled into the assembly. A lot of times, we just put it in the .cs file that has the "main" method, and it works just fine.
Well, thinking a little differently, you don't have to have only one assembly info file.
This is how we do it for a solution, each project has 3 assembly info files:
AssemblyInfo.cs - Contains Guid, AssemblyTitle, AssemblyDescription, and any assembly specific attributes.
ProductAssemblyInfo.cs - Contains AssemblyProduct, AssemblyVersion and AssemblyFileVersion. This way all assemblies in a product/solution share the same version.
CompanyAssemblyInfo.cs - Contains AssemblyCompany, AssemblyCopyright, and any attributes we want all our assemblies to share.
Items 2 and 3 are referenced using "Add as link", this way they are shared from the single source code. Now, you may not want to adopt the same approach, but you could certainly use a similar structure and place your XmlConfigurator in a separate assembly info file from your assembly version details.