We have a Powerbuilder 10 application that is using .Net COM assemblies. We are trying to embed the manifest in the PB application (to invoke COM assemblies without registration). The merged manifest file has added sections for dependecies on the .Net COM assemblies. We have tries various tools to inject the new manifest with different results
- using GenMan32 to inject truncates the application from 6MB to 45KB.
- using ResourceTuner, the file size looks okay, but trying to launch application gives "Fatal Disk Error".
Any suggestions on invoked .Net ComEnabled assembly from PB without registration?
Have you tried it with an external manifest and ensured that works? If an external manifest doesn't work, then the manifest information isn't correct.
Once you have a valid external manifest, you might try the Manifest Tool (MT.EXE) from the .Net SDK. It works well with true EXE files. As Terry noted though, the PB generated executable contains additional information that tools that manipulate the EXE need to respect or they will break it.
http://blogs.msdn.com/patricka/archive/2009/12/09/answers-to-several-application-manifest-mysteries-and-questions.aspx
This is more a redirection than an answer. One thing you need to be aware of is that PowerBuilder produces executables that do not follow standards for Windows executable files. Essentially they are a bootstrap routine to load the PowerBuilder virtual machine, plus a collection of class definitions (objects). The cases you've brought up are not the first I've heard of where utilities meant to modify executables don't work on PowerBuilder executables.
As for a positive contribution on what other directions to follow, I don't really know enough to give qualified advice. If it were me, I'd try to register the COM object if ConnectToNewObject() fails, but I've got no idea if that possible or if that route is a dead end.
Good luck,
Terry.
Related
I'm building a windows mobile 6.0 application and I wanted to use restsharp library to consume data from a rest service. I've found information that RestSharp can be compiled for compact framework 3.5 (as is not available from the official site).
But, does anybody have successfully compiled the assembly for CF? If yes, could anybody provide a link to download the assembly. Thanks
I do not know a download location for the ready-to-use assembly.
I would start a new CF2 project and in another instance of VS open the original restsharp solution. Additionally open two file explorer to copy files of the restsharp source to the new CF2 project directory. You should maintain the same solution layout and folders (if any). Then copy the files over to CF2 dirs and use Add Existing Files in the CF2 solution. You need to use the same namespace and project and solution names (makes live easier).
Now try to compile. If you are lucky, everything compiles without error. But mostly you have to either adjust code or write CF2 compatible wrappers. If there are two many FullFramework constructs that can not be 'emulated' in CF2, you may have to give up. But as you said, there are CF compatible sources.
You mentionend CF3.5 and asked for CF2. Possibly RestSharp will only compile as CF3.5 assembly.
See also: RestSharp: Don’t Serialize null Properties
BTW: the GitHub repo (https://github.com/restsharp/RestSharp) shows a CF solution file RestSharp.Compact.sln and RestSharp.Compact.csproj. These should work with VS2008.
I have a DLL written in C# and set for COM visibility. I have it setup as a side-by-side assembly and can successfully deploy the application to client PCs registration free. My question is related to the development PC. Is it possible to compile against the DLL in a similar registration-free manner or is registration required on the development machine? I have tried adding the DLL directly though the Project -> References menu and get an error stating "Can't add a reference to the specific file." The DLL is sitting in the same directory as the .vbp file and I have tried adding the DLL both with and without the client app manifest being present.
I have tried adding the DLL directly though the Project -> References menu
That adds a reference to a type library. A type library is a language-independent description of the types in a COM component, VB6 uses it to know how generate efficient code and to provide type checking and auto-completion. A type library is the exact equivalent of metadata in a .NET assembly.
Traditionally, and the way VB6 did it, the type library was embedded as a resource in a DLL. So you are probably used to picking a DLL in the dialog. That however doesn't work so well when the DLL is generated by C#, the type library can only be generated after the C# code is compiled. You have to pick the .tlb file in the VB6 dialog. The traditional way starts with the COM component being described in the IDL language, the type library can be generated before the code is compiled so can easily be embedded in the final DLL. It is technically possible to do it in C# as well, but the build steps are very laborious and painful, you essentially have to build the DLL twice with different build commands.
The type library for a C# library is normally generated in one of three ways:
Using Project + Properties, Build tab, "Register for COM interop" option. This requires VS to run elevated so it can write to the registry. You start VS elevated by right-clicking its shortcut and picking "Run as Administrator"
By running Regasm.exe, using the /tlb:filename option. An alternative for the 1st bullet and necessary if you don't want to run VS elevated for some reason. Using the /codebase option on your dev machine is also wise to make it work exactly like the 1st bullet and not require putting the DLL into the GAC with gacutil.exe
By running the Tlbexp.exe utility, the type library exporter for .NET assemblies. No registration is done, it only generates the .tlb file.
The first bullet is the normal choice and very desirable because you can never forget to update the type library this way. It is perfectly fine on a dev machine since you only really care about reg-free deployment on the user's machine. You probably got into trouble by not doing this anymore.
Using the 3rd choice is okay and more compatible with your goals, run Tlbexp from the Visual Studio Command Prompt. Just keep in mind that you have to do it again when you make changes to your C# code. Forgetting this once and losing clumps of head-hair trying to figure out why your C# changes don't seem to be effective or getting hard-to-diagnose error codes gives you lots of reasons to consider the 1st bullet again :) You can emulate the reg-free scenario by running Regasm.exe with the /uninstall option.
This is driving me crazy. I have developed a .NET COM DLL that is used by a VB6 DLL wrapper in order to update and replace some legacy functions in an application.
I am now trying to remove the requirement to use regasm on client machines so have worked out how to do that on a test DLL which all works fine.
I branched the DLL just in case and added an app.manifest file. Everything else worked out fine and I got it all working. The manifest is embedded and Visual Studio 2012 generates a mydll.dll.manifest file in the release folder.
Then I went back to the original trunk and added an app.manifest file (no point in merging as there were no code changes). I copied the contents of the branch into the app.manifest file and built the release version. The manifest is embedded in the DLL but no mydll.dll.manifest file is generated.
I know that it's not strictly necessary to have the mydll.dll.manifest file but I'd like things to be consistent (and for some reason the test process doesn't produce the same results with the trunk version) so how can I force it to be created?
This is a VB.NET DLL project so it doesn't have (or I can't find) the 'Generate Manifest' property drop down mentioned in the first answer here. How can I set this? Or is there a way to set it by editing the project file directly?
References:
Original walkthrough article and some corrections.
Overview by Junfeng Zhang in two articles plus a useful tool
You are making a fairly common mistake. A reg-free COM manifest helps an application find a COM server without looking in the registry to locate the DLL. Embedding the manifest in the DLL is like trying to solve the chicken and egg problem, Windows cannot possibly find that manifest if it cannot locate the DLL first.
The manifest needs to be part of the client app. Which is tricky since it is VB6, it doesn't support embedding manifests in its executables.
You could tinker with the mt.exe tool, an SDK utility that supports embedding manifests in an executable. You'd have to run it by hand after building the VB6 binaries. That's unfun and very likely to cause trouble when you forget. It is in general not a joyful tool to use, documentation is meager, incomplete and unhelpful, a chronic problem with manifests.
The fall back is a separate app.exe.manifest file, what Windows will look for next when it cannot find a manifest embedded in the executable. Where "app.exe" must be renamed to the name of the VB6 program. The EXE, not the DLL. This now also gives you a chance to avoid having to register the VB6 DLL, presumably what you really want if you truly want to make your program run reg-free. The disadvantage is that it will not work when you debug your VB6 program, wrong EXE. You'd also need a vb6.exe.manifest, located in the VB6 install directory.
Needless to say perhaps, very hard to get ahead with VB6 here. It just wasn't made to help you do this, they didn't have a time machine in 1998.
I have to admit that I don't know VB at all, but in the case of C++ and C# Visual Studio projects I previously had to resort to calling mt.exe in a post-build step in order to get the DLL manifest I wanted. Maybe that workaround would work in your case as well?
I've been able to create a signed CAB file for web deployment containing my control and dll, but my control seems unable to access classes and functions in my dll even though it is listed as a dependency in the CAB's inf file. For all my research, I can't even tell if what I'm trying to do is "allowed". Followup: if it is possible to talk to a non-com dll, is it a security risk?
I'm using msvc 2010. Thanks for your time!
Pretty certain what I was trying to do wasn't possible. Ended up creating a class library instead so that I could reference and include the functions I needed at compile time.
So, I've got a single VB6 executable that references multiple VB6 COM DLLs. Is it possible for me to generate, on-the-fly, a manifest for the executable as well as a manifest for each of the referenced DLLs? If so, then how?
I would like to perform this operation as part of our build process without having to register the COM DLLs as part of the process.
NOTE: All the reg-free COM examples that I've found so far involve .NET interop, which is not a requirement for what I'm doing.
[EDIT]
After performing some preliminary testing using Unattended Make My Manifest, I've found that its just not as user-friendly as I would like. And, since there's only a Sample.ini file for documentation I've had a pretty hard time understanding what should be put into that file compared to what doesn't need to go into that file. Anyways, I've decided to craft manifests using my own tool. Hopefully, I'll get permission from my employers to release the code as open source.
*For now, if you're in the same position that I'm in and you would like to create a build and production environment that uses side-by-side/registration-free COM interactions, just know that its possible. I would recommend crafting them by hand with a simple DLL and consumer app at first, and then incrementally building on that until it suites your specific needs.**
We are using Unattended Make My Manifest in daily builds to create portable versions. It creates a single manifest that can be embedded to the executable with mt.exe
You could try Make my manifest which is a tool to create the manifest for a VB6 program. I don't know whether it can run automatically as part of a build process.