I have to build OEM versions of a COM library (DLL).
Does anyone know a tool (ressource hacker) which may replace some of my interface guids after build time?
I just want to build and test one DLL and generate the OEM versions afterwards.
No tool that I know of. You could use an automated build process to actually build dll#s with different GUID's.
Replacing interface ids in the compiled binary is not that easy. They are usually hardcoded and the compiler allocates them in static storage and they might even have static linkage so you will have problems finding them. Remember how QueryInterface() is usually implemented?
HRESULT CImpl::QueryInterface( IID& iid, void** result )
{
if( iid == __uuidof( IInterfaceThisClassImplements1 ) ) {
*result = static_cast<IInterfaceThisClassImplements1*>( this );
} else {
///same stuff for other interfaces
}
//call AddRef() if succeeded
}
It's not limited to resource editing, you have to actually patch the static data of the binary image and likely no tool will be able to do this automatically for you.
Since you have the full source your best bet is to just rebuild the binary.
Related
I have an iOS app with some business logic. I would like to create an executable which would expose some calculations from the cli, so that I don't have to use the app.
Unfortunately, the code with the business logic that I want to expose depends on lots of other parts of the code, eventually pulling almost all the code. Even worse, it depends on some dependencies that are not available on macos (UIKit or DJISDK via pods).
I just want to write a main.swift, parse the arguments and use some functions from the codebase. What is the simplest way to do that ?
I don't mind if it's ugly (like pulling whole of UIKit in the executable) as long as it doesn't take to much time to implement.
I have two ideas:
remove all dependencies, optionally defining "dummy" classes compiled only for this target for some dependencies. That requires changing a lot of code, but seems to be cleaner.
find a way to pull the whole app in the new target. For example I have a UnitTests target which does that and can run on mac (though an app window appears when the tests run). But I have no idea how to do that.
Any help or guidance to good documentation would be greatly appreciated :)
I did my best to remove all unneeded dependencies, but there was a lot left that couldn't be removed easily. I resulted in using "dummy" classes to be able to compile without providing any logic.
Though it's not super elegant, it's a nice way to cut the dependency chain, and will let me remove the dependencies over time, while still being able to compile.
Ex:
// In common source file
class Business {
func usefulComputation() -> String {
...
}
func unneededFunction() -> UselessObject {
...
}
// In my CLI-target project
// file `DummyUselessObject.swift`
class UselessObject {
// add any function called from source file here, without putting any logic
}
// `main.swift`
let business = Business()
print(business.usefulComputation())
I have an app which works great in the development environment but misbehaves when deployed as an EXE. When I click deploy and make an EXE, all of my queries which are run through DataStore objects succeed (SQLCode 0) but return zero rows. Out of frustration I changed to visible datawindows and it magically worked again under an EXE. So I made the datawindows invisible and it continued to work. This is just bizarre. I have another powerbuilder app which is much larger, uses lots of DataStore objects (on the same database) and those work great.
DataStore ds_wacn
ds_wacn = create datastore
ds_wacn.DataObject = 'd_plateaccessions'
ds_wacn.SetTransObject(SQLCA)
ds_wacn.Retrieve(sLoad, iPlate)
IF SQLCA.SQLCode < 0 then ...
// Succeeds in development, fetches zero rows under EXE
dw_wacn.SetTransObject(SQLCA)
dw_wacn.Retrieve(sLoad, iPlate)
IF SQLCA.SQLCode < 0 then ...
// Succeeds in development and in EXE
I was very careful to make sure that the app that works and the one that fails are using the same settings to connect to the database (but still could be a problem there). This is Powerbuilder 11.5.1
Very likely your DataWindow object isn't being compiled into the EXE.
When you compile an EXE, PowerBuilder starts at the Application object and intelligently tries to determine which objects should be included. Since d_plateaccessions is only referenced in a string in a script, it isn't included.
There are two ways around this.
You can create a PBD for the PBL containing the DataWindow. PBD creation blindly includes all objects in the PBL. This method is quite popular, and many people just mark all their PBLs for PBD creation and deploy the PBDs.
You can alternatively create a PBR for the EXE, telling the compiler to force certain DataWindows and graphic files into the EXE. If you really want a single EXE, but don't want the effort of building an appropriate PBR, you can use PBL Peeper to generate PBRs and scripts to force all DataWindows and objects (and find all relevant graphics) into a compiled EXE, using the PBR Builder Plus report.
Good luck,
Terry.
I have a problem with your first 4 rows.
DataStore ds_wacn
ds_wacn.DataObject = 'd_plateaccessions'
ds_wacn.SetTransObject(SQLCA)
dw_wacn.Retrieve(sLoad, iPlate)
Do you really retrieve on dw_wacn instead of ds_wacn?
And there isn't "create" for your local datastore.
I don't use frenquently local datastore but in this case the code is like this in our program
dataStore ds_myDs
ds_myDds = create datastore
ds_myDds.DataObject = 'myDataObject'
ds_myDds.SetTransObject(SQLCA)
ds_myDds.Retrieve( /*arguments or not*/)
/*
some code
*/
destroy ds_myDs
I'm currently using MEF and a DirectoryCatalog to load some parts from some extension DLLs. It works for me, and most of the people that use the program, but some users experience the parts not being loaded at all. Collecting some debug information, it seems that MEF does load the DLLs (catalog.LoadedFiles lists them), but that no parts are listed in catalog.Parts.
One user is on XP sp3 and one is on Windows 7, so I don't think that the OS is the problem. Does anyone have some idea of why this would be happening?
The following is the code that actually creates the container, in case it would help with anything.
private static IEnumerable<Task> CreateTypes()
{
CompositionContainer container = GetContainer();
var exp = container.GetExports<Task>();
return exp.Select(e => e.Value);
}
private static CompositionContainer container;
public static CompositionContainer GetContainer()
{
if (container != null)
return container;
DirectoryCatalog catalog = new DirectoryCatalog(ExtensionDirectory, "*.dll");
container = new CompositionContainer(catalog);
return container;
}
(Yes, I'm answering my own question...more than a year later...)
http://mikehadlow.blogspot.com/2011/07/mef-directorycatalog-fails-to-load.html
Basically, because some people downloaded the program using IE then unzipped with Windows Explorer, the DLLs were marked as being from the internet, so MEF refused to load their parts, though they still showed up inside the catalog.
The solution (for my situation at least) was simply to delete the alternate data streams that said that the DLLs were from the internet, as described in the above link.
but the other one is in "C:\Spiele" which sounds like a user-created folder
Reminds me of this:
Assembly Load Issues
In .NET, there are different contexts into which an assembly can be loaded. The default load context is generally the best one to use, but it cannot load assemblies that are not in the application base directory, subdirectories of the application base which are included in the probing path, or the GAC. When using a DirectoryCatalog or passing a path to the AssemblyCatalog constructor, MEF will attempt to load assemblies in the default load context. However, if the assemblies are not in the probing path or the GAC, this will not be possible, and MEF will load them in the load-from context instead.
The load-from context can lead to type identity issues that result in an InvalidCastException, MissingMethodException, or other errors. In order to avoid these issues in a MEF application, you can put any extension directories under the application base directory, and add them to the probing private path in your application configuration file. For other options and more information about assembly loading in .NET, see the Best Practices for Assembly Loading MSDN document.
See the source "How to Debug and Diagnose MEF Failures" for more debugging information and tools.
I'm currently making good use of GWT's ClientBundles in my app. It works fine, but I have a large number of resources and it becomes tedious to manually create Java interfaces for each file:
#ClientBundle.Source("world_war_ii.txt")
public ExternalTextResource worldWarII();
#ClientBundle.Source("spain.txt")
public ExternalTextResource spain();
#ClientBundle.Source("france.txt")
public ExternalTextResource france();
I'd like to be able to (perhaps at compile time) dynamically list every *.txt file in a given directory, and then have run-time access to them, perhaps as an array ExternalTextResource[], rather than having to explicitly list them in my code. There may be hundreds of such resources, and enumerating them manually as code would be very painful and unmaintainable.
The ClientBundle documentation explicitly says that "to provide a file-system abstraction" is a non-goal, so unfortunately this seems to disallow what I'm trying to do.
What's the best way to deal with a large number of external resources that must be available at run-time? Would a generator help?
There's an automatic generator for CssResource - maybe you could look at its code and modify it to your needs?
I ended up following this advice: perform the file operations on the server, and then return a list of the file (meta)data via an RPC call.
This turns out to be fairly simple, and also allows me to return lightweight references (filenames) in the list, which I use to populate a Tree client-side; when the user clicks on a TreeItem the actual text contents are downloaded.
I have been using CodeDom to do some code generation. It works great, but I haven't found a way to include the generated source code files in a project. I started using T4 and the T4Toolbox to generate code because it supports integration with project files.
Does anyone know if CodeDom supports this functionality too? I'd consider taking a second look at CodeDom if it only supported this one feature.
Here is an example of how I make a source code file with CodeDom:
protected void CreateSourceFile(CodeCompileUnit codeCompileUnit,
string fileName,
out string fileNameWithExtension)
{
fileNameWithExtension = string.Format("{0}.{1}",
fileName,
CodeProvider.FileExtension);
var indentedTextWriter =
new IndentedTextWriter(new StreamWriter(fileNameWithExtension,
false),
TabString);
CodeProvider.GenerateCodeFromCompileUnit(codeCompileUnit,
indentedTextWriter,
new CodeGeneratorOptions());
indentedTextWriter.Close();
}
That works fine but it just outputs the file to the hard drive somewhere (probably bin folder).
Here is a second example of some code I use with T4, this one specifies the output as part of the project the template is transformed in:
public class RDFSClassGenerator : Generator
{
private readonly string rootNamespace;
private readonly string ontologyLocation;
public RDFSClassGenerator(
string rootNamespace,
string ontologyLocation)
{
this.rootNamespace = rootNamespace;
this.ontologyLocation = ontologyLocation;
}
protected override void RunCore()
{
XElement ontology = XElement.Load(ontologyLocation);
var service = new RDFSGeneratorService(ontology);
foreach (MetaClass metaClass in service.MetaClasses)
{
var rdfsClassTemplate = new RDFSClassTemplate(rootNamespace, metaClass);
rdfsClassTemplate.Output.File = "Domain/" + metaClass.Name + ".cs";
rdfsClassTemplate.Render();
}
}
}
So the T4 code will output the file into the "Domain" folder of my project. But the CodeGen stuff just outputs the file on disk and doesn't update the project file.
Here is a visual:
Yes, it can. Here is how: http://www.olegsych.com/2009/09/t4-and-codedom-better-together/
Short answer is no, but I could be wrong (ever try to prove a negative?)
Your question was a little confusing as CodeDom isn't exactly equitable with T4. T4 templates are a convenient way of generating code files the same way, for example, asp.net generates HTML files, mixing text and code that gets executed to generate a file that is then interpreted by something else (such as a compiler or a browser). CodeDom is usually used to generate assemblies at runtime rather than files, although you can do it (as you have discovered).
While T4 makes it easy to add files to the solution, you can do this with CodeDom as well. I don't believe it supports interaction with the solution directly, but you can manage this using EnvDTE, or the automation model for Visual Studio.
The problem with this is that the automation model isn't easy to work with. EnvDTE is a wrapper around COM classes, which is always fun to code against. Also, you have to be careful when attempting to get the object. The naive implementation will get the object from the first instance of Visual Studio loaded. You have to poll the Running Object Table to find the current instance. Once you have it, you must deal with searching through the dte for the location you're looking for, deal with source control, locked files, etc etc.
Working with it, you start to learn why T4 was created in the first place.
The question you have to ask yourself is, "Does CodeDom give me enough that T4 doesn't to make up for all its shortcomings?"