I would like to put the Z3 (V3.2) assembly into the GAC, but it is not signed.
Is there a reason for that ?
The 64 bit managed DLL is built with a self-signed key, the 32-bit DLL is not. This looks like a bug and I will check if we can add a workable delay signing to the 32-bit version as well. We don't build already signed assemblies, but components that use Z3 have so far been able to integrate delay signed assemplies that we provide per requests.
Related
I've setup NSass from NuGet. It's a managed wrapper around libsass and has a HTTP handler that does on-the-fly compilation of .scss files to CSS.
The problem is that the handler throws the following arcane InvalidOperationException:
Found NSass.Wrapper.proxy.dll which cannot exist. Must instead have
NSass.Wrapper.x86.dll and NSass.Wrapper.x64.dll. Check your build
settings.
I can see that the code and message is copy-pasted from some trickery found here (see bottom):
Load x64 or a x86 DLL depending upon the platform?
So my guess was that my web project needed to target x64 specifically, maybe to force a decision on the unmanaged library being used.
That just ends with a BadImageFormatException maybe due to IIS Express being 32-bit which I've seen being a PITA with Oracle dependencies - I gave up then, too.
I think, due to the unmanaged library, AnyCpu cannot be used for the project, instead you must pick a target processing platform.
For me that's 64-bit but IIS Express is a 32-bit process. I recall having similar issues with unmanaged references, bitness and IIS Express (32) vs. production (64) with Oracle libraries.
So when IIS Express tries to load the x64-targeted website assembly, it blows up.
I am now looking into a compile time CSS compilation, rather than runtime, using Web Workbench or something.
I got the same issue, and the reason for it was that the NSass.Wrapper.XXX.dll files were not copied into the output directory.
Sometimes in s/w companies, customers provide data in multiple formats. There are linkable and executable data that are said to be "Rehosted" and compiled object files that are said to be "Retargeted". I am trying to understand what rehosting and retargeting mean in this area. Is it similar to the Bootstrap theory in computer science? I have the understanding of the following process (if not incorrect):
PROBLEM:
I need to write a compiler for a new language called "MyLang" to run on PowerPC
Solution:
1. I need to write a compiler for a language "MyLang-Mini"; a subset of "MyLang" to run on PowerPC.
2. I need to write a compiler for "MyLang" using "MyLang-Mini" to run on PowerPC.
3. I run the compiler obtained from no. 1 through the compiler obtained from no. 2 to
obtain the compiler for MyLang to run on PowerPC.
IN BESPOKE "T" DIAGRAM (...ISH):
MyLang PowerPC MyLang PowerPC
MyLangMini MyLangMini PowerPC PowerPC(instr.)
PowerPC(instr.)
What I am getting confused about is rehosting and retargeting. How are they coonected to this concept? What am I rehosting and retargeting if I have some binary data such as .exe or .obj? I would appreciate some detailed explanation if possible please!
I know that this will embark onto "CROSS-COMPILERS", but would prefer expert opinions to be sure.
Thanks in advance.
I now know that in s/w engineering:
REHOSTING - If you have a third-party application linkable/executable that requires usage on your host machine, you do rehosting. The target in this case are most often the same (OS platform, processor, etc.). In worst case, there is a virtualisation required. The rehosted application will run as if it was one of the application running in the host machine
RETARGETTING - If you have a third-party source code, you might need to recompile that to match with your target environment. It may also be that you have third-party .o or .obj compiled models and you want to link them with your source code (retargeted) in order to host it on a host machine. Just like REHOSTED application, it will be as if the application was installed on the host machine.
It will be good to know how this is similar to the compiler rehosting and retargeting. Sorry, I am a newbee is this area and will appreciate even a slap on the wrist.
We have an old VB6 project that uses ActiveX controls, some of which we build and others we get from third-party vendors.
Currently, we use a .csproj project which does the following,
Execute regsvr32 to register the OCXs
Execute vb6 to build the VB6 project
Execute regsvr32 to unregister the OCXs
This registering/unregistering is ugly and is a bit of a pain for local developer builds with UAC enabled. Is it at all possible to build a VB6 project without having to register any controls?
I apologize if this has already been asked before. The only similar questions I was able to find were about how to build VB6 projects, and answers to these mention the same solution of register, build, unregister.
It sounds like these people are merely working on clients of these OCXs rather than modifying and recompiling the OCXs themselves.
If so, you should be administering the installation of these libraries just as you administer the VB6 development system itself. This means each workstation needs to have the control suites you are using installed once (well, and maintained when new releases are placed into use). Installers for developer libraries deploy things like .DEP files as well as design-time license key registry entries, so using regsvr32 shouldn't be considered a viable strategy anyway.
If you set the developer workstations up properly and maintain them there isn't any reason to be registering and unregistering such things.
It means the original developers probably did not set the "binary compatibility" correctly. Which means the VB6 dll's get a "new com guid" every time they are built.
Which means your original VB6 developers were probably a bunch of hacks.
You can read the section here on Binary Compatibility.
http://support.microsoft.com/kb/161137
Get in a time machine and go back and punch the person in the face who said "We don't need
to work out the binary compatibility issues now, we'll just unregister and re-register the components... Easy Peezey!"................
If I'm wrong, please let me know. But every time I've seen "unregister the com" and "re-register the com".........it goes back to that brainiac decision.
Here is a longer discussion on it:
http://www.techrepublic.com/article/demystifying-version-compatibility-settings-in-visual-basic/5030274
EDIT:
If the ocx's are not changing........then you should only have to register them once on the build machine once.
The direct answer is no, it is not possible to compile a VB6 project with OCX dependencies without those dependencies being registered.
Furthermore, the act of compilation itself involves VB6 attempting to register what it has just built (unless you are compiling to an EXE). This generally requires the VB6 IDE and/or its compiler to run with "admin" permissions. Therefore the permissions are a hard to avoid issue regardless.
I believe these issues can be obfuscated by the fact that VB6 itself (the IDE and/or the runtime) will sometimes try to automatically register certain things for you, but will keep silent when it does so.
You should probably create a different process to setup a development PC from the build process you use from deployment. This may "feel" wrong especially if you have experience with other programming environments, but I would stress that VB6 can be very painful & problematic to work with and so pragmatism is generally in order.
On the development PCs: Setup all the unchanging dependencies once (and document them) and then leave them alone (as noted in another answer.) When weird dependency problems occur, verify the PC is setup correctly before doing anything else.
If you have all the sources to your dependencies, then I would consider if you can actually run them all in a VB6 project group (VBG) and not compile them at all. (A VBG is akin to a .NET solution though far less powerful.) I do this often and it cuts out a lot of wasted time. Developers don't necessarily need code compiled to EXE / DLL / OCX - they often just need to be able to run it in the IDE.
On the build PC: If you can always start with a clean environment, like in a virtual machine, then I think its actually a good idea to register everything from scratch in an automated fashion as this helps to verify nothing is missing or mismatched. Re-using the same build environment without doing this can mask problems when some dependency has changed in source control but still exists on the build machine. On a VM generally permissions aren't a limiting factor.
Notes:
If you are building an EXE, VB6 does not require any elevated permissions, as far as I can recall.
Running code in the VB6 IDE does not either.
[Caveat 1]:
It may technically be possible to create a side-by-side application manifest file for VB6.exe itself and include in that manifest whatever dependencies you need, thereby avoiding having to register them.
But this would fall well outside of the normal ways to use VB6 tools - its a hack - and possibly is not worth the potentially large effort. I don't think I've ever seen a working example and so I don't recommend this as a practical solution, but mention it for completeness.
Maybe in some locked-down corporate IT scenario this could pay off... maybe. In that scenario doing dev work in a VM might be a better option though.
I made a simple application that uses Indy and requires OpenSSL dlls.
I am not going to write an installer for it, so I have 2 options:
1) deploy it by copying the application exe + libeay32.dll + ssleay32.dll in the same folder
2) put libeay32.dll and ssleay32.dll in the exe resources and extract them to the applicationpath on program start (but this can may be a problem in case I am running the exe on a windowsserver 2008 or windows vista and I used the Program Files folder to "deploy")
Can you comment on those techinques or suggest a better approach?
You could stick with option 1) :D
Or, you could use a variation on number 2, but extract them to the application data path:
GetSpecialFolderPath(CSIDL_LOCAL_APPDATA))
and use
SetDLLDirectory(DirectoryPath:PWideChar)
to specify where to load dll's from
Of course, to be perfectly honest, it's quicker just to write a simple installer!
Edit:
Oh, and yes, as UnixShadow mentioned, hash the dll's so you can be sure that you're using the correct files!
Option 3: use Inno to install it! You may have a good reason for not wanting to use an installer, but in case your reason is you think it's too expensive (in time or money), you might check out Inno. I started using it earlier this year and was amazed at how easy it is to learn and use. And, it's free!
Of course the side benefit of learning Inno is that you'd have it available in the future for other projects...
Depending on the nature of the application, you could consider compiling it with Lazarus.
I know, I know, it is a far stretch, and I don't know sb who has actually done this with openssl, so it is probably too much work. Still I wanted to make a note of this theoretical solution.
This because FPC/Lazarus is mingw compatible, and can use the same (GNU linker), you could try to link mingw libs (.a's) statically.
Some people in the past have experimented with it, and I have heard people succeed in this with mysql, but unfortunately they didn't give details.
So I have no conclusive proof that it worked, which makes it a bit academical.
I would install them in the same folder (option 1), with the addition to actually MD5 the two dlls when starting my program. To try to verify that they haven't been modified. This does not help a lot when it comes to security cause a hacker might as well modify my MD5 sum I would compare against. But it would at least stop the program from using corrupt dlls. Ofcourse this would also block out the possibility to update the dlls without updating the main application (on good an bad).
Where can I find a good reference that explains how to write and install a SxS policy redirecting from one native assembly version to another?
I've already succeeded in building and installing two versions of my native assembly using a wix installer. But I'm not sure how to proceed from here. Most of the information I've found is about managed assemblies and the GAC. Is the procedure I'm looking for identical to that of managed dlls?
Thanks for the help,
Dan
[I'm the current maintainer for Native SxS at Microsoft]
Hi Dan,
A Publisher Policy is a special type of assembly. It's installed in the same way as any other assembly, but with type="win32-policy" and name="policy.MAJMINVERSION.name"
You can read more about it here
or you could look at how the CRT's policy is authored. On my Vista machine, it's located under
%windir%\winsxs\manifests\x86_policy.8.0.microsoft.vc80.crt_....manifest
Since it seems you are authoring a new assembly, providing a publisher policy just yet may not be necessary, as it only comes into play when it comes time to service your assembly (by redirecting old version to new).