I am trying to provide VIEW access to the GAC. Ideally what I want is for them to see the contents of the assembly folder as you see it in Windows explorer (ie with version number and so on). I am happy to list this in a text file and provide that to them. But I can't figure out how to do this.
Note: this is a server is not a development machine, so we do not have the SDK installed to use gacutil. Also, I don't to remove/install items in the GAC. Just to view it, so gacutil is a little to powerful in that respect.
I am the author of an free and open source PowerShell module called PowerShell GAC that could help you. The following will print out the contents of the GAC.
Get-GacAssembly | Out-Printer
You can also filter the assemblies on name for example, or have it sent to a file with Out-File, or show other columns like the file version besides the assembly version.
Related
Hi DocuSign CLM geeks and the DocuSign API in-house team-
Our team will be using DocuSign CLM with the DocuSign Edit add-on to easily open Microsoft Word files and save back to CLM.
We'd like to include the installation of DocuSign Edit in our Silent Mode installation configuration. We're hoping there's an msi File available for the DocuSign Edit extension? If so, please link!
Plan B- If we were to make our own msi from the available exe, does anyone have a trail stomped out for doing this? (a blog post, documentation, step by step, video demo, even a horror story)
Thanks for tips.
https://tools.springcm.com/sites/default/files/apps/docusign-edit-pc-2.01.00.exe
This is an exe that is built from an MSI, so it is an MSI.
If you want to get the MSI out of this https://www.codetwo.com/kb/msi-from-exe/:
The first method is based on the fact that most installers extract their .msi files to the temporary files folder during the installation process. To extract an MSI file from an EXE installer, you need to:
Launch your .exe file.
When you see the first prompt (e.g. a question about whether you want to continue installation, accept a license agreement, etc.), do not click anything in this window and do not close it.
Open Windows Explorer, type %temp% in the address bar and press Enter.
Sort the files in the folder by the modification date. The newest file on the list should be the .msi file you are looking for.
Copy the MSI file to a safe location before you close the installer prompt window (see step 2). Be aware that if you close the installer window, the MSI file will be immediately deleted from the temporary files folder.
The second method uses a free third-party tool called 7-Zip to browse the content of the .exe installer file. Follow the steps below.
Download 7-Zip from this page and install it.
Right-click on the .exe file (from which you want to extract an .msi file) and from the shortcut menu choose 7-Zip > Open Archive.
Do not extract any files yet. Instead, browse and look for the folder MSI within the contents. It might take some time to find this folder because it is not always located directly in the root directory (its location may vary depending on the installer).
When you locate the MSI folder, you will notice that it most likely does not contain any .msi files, but a file or files with no extensions and rather cryptic names such as 132. Despite these misleading names, these are actually the MSI files you are looking for.
Drag and drop these files to any desired folder or select them and extract them with 7-Zip. Close 7-Zip after that.
Change the names of the extracted files so that they include the .msi extension.
If there are two files, the larger one is the 64-bit installer, and the smaller one is the 32-bit version. Use the one you need.
Finally, if you want to tweak an MSI, you can use the Orca tool by Microsoft - https://learn.microsoft.com/en-us/windows/win32/msi/orca-exe
I have a customization project where I'm importing an Excel file content into the Lot/Ser No. Allocation grid. This works fine on my machine, but I had to download the DocumentFormat.OpenXml dll and include a reference in my class library project in order to do this. I've created a customization project, but when someone else tries to use it, that reference and that file are not there. I've tried to include it in the files section of the customization manager, but I have no way of doing that (can't browse to a file) - not that that would make any difference anyway, since that's the bin folder of the website, and not the class library.
Bottom line: Is there a way to include a dll file that's used in the class library project references in a customization package?
Add the dll file in Bin folder of your local website -> the file should appear in the Add Files dialog inside Customization Project Manager
Select the dll file in the Add Files dialog and click Save
After that, DocumentFormat.OpenXml.dll becomes a part of your customization package, which will always deploy it together with your extension library
Ruslan provided a good answer explaining how to include your custom DLL, however you might want to know that there are built in functions to read Excel files which make inclusion of third-party libraries unnecessary. Please refer to the following article: http://asiablog.acumatica.com/2016/03/reading-excel-file-acumatica.html?m=1
I'm new to C++/COM. I have created a ATL COM Project with a callback mechanism to send messages to managed side. It has one idl file (sample1.idl) which expose 'n' number of methods, hence managed environment can access it. Now i would like to add another .idl(sample2.idl) file to that project.
.tlb is created for both sample1 & sample2 and build succeeded. On browsing the .dll , I couldn't find the sample2.idl related stuffs. I suspect that .tlb generated from ‘sample2.idl’ is not reflected in the .dll.
Can we have more than one IDL’s in the ATL (COM) project ?
The default for ATL, as with many native build environments, is to embed the type library as a resource in the DLL. Something you can see in Visual Studio (retail edition required), use File + Open + File and select the DLL. Open the "TYPELIB" node, you'll see one type library with resource ID #1. This is the one that Visual Studio sees when you use Add Reference.
Most any build tool that consumes type libraries will only ever look for that one resource. Visual Studio is no exception. It also can encode only one type library in its project files. You perhaps can make it work by selecting the 2nd .tlb file with the Add Reference dialog. Albeit that it is very likely that you'll now get exposed to more problems in your ATL project, like forgetting to register that 2nd type library in your .rgs file.
Very hard to give proper advice without any hint what that second IDL file might contain. Stay out of trouble by merging them or by using the existing support in IDL to import other .idl files or type libraries.
I want to verify if certain exe files already exist in a merge module .ism (binary format). Is there a method of doing this without using InstallShield?
An *.ism file is really an MSI file with a changed extension. MSI files in turn are SQL databases stored as COM-structured storage files - a file system inside a single file with file streams for various content. This is the same format used in Office documents.
You can view MSI files with Orca from the Windows SDK: http://www.hass.de/content/how-install-microsoft-orca
Windows Installer XML (WiX) Deployment Tools Foundation (DTF) has an InstallPackage class available that exposes a FindFiles() method. This should be really easy to query the EXE. Just realize that being a merge module you won't know the full installation path as that's decided by the MSI generally.
Both of Chris's suggestions should work fine, as would using Orca. But it got me thinking there might be an even easier way using a tool called Merge Module Finder. It all depends on what you really want to do? Find files already in merge modules? Investigate what merge modules are in an Installshield file? It is not quite clear exactly what you want to do.
Though a bit clunky at times (I think the author hasn't updated it for the latest versions of Windows) it will help you look for a file in a bunch of merge modules interactively. You can also search for a registry value. Here is a screenshot:
Our product includes several DLLs built from open source into files with default names as delivered by the open source developers. We're careful to install the files in our own directories and we carefully manage the search path (only for our processes) to keep the loader happy.
Another developer -- a towering intellect -- decided it would be easier to install their own build of some of the same open source into C:\WINDOWS under the same default DLL filenames. Consequently, when we launch a process which depends on these open source DLLs, the system searches C:\WINDOWS before our directories and finds the DLLs installed by the other developer. And they are, of course, incompatible.
Ideas which have occurred to me so far:
rename all our DLLs to avoid the default names, which would only make
it less likely we would encounter collisions
load all our DLLs by full path so the loader captures their names into
RAM and doesn't search anywhere else the next time they are requested
For various reasons, neither of these options is palatable at the moment.
What else can we do to defend ourselves against the towering intellects of the world?
You've got only two options: deploy the DLL in the same directory as the EXE (that's where Windows looks first) or using manifests and deploy the DLL to the Windows side-by-side cache. I don't think the latter option is common in the Open Source world but it is the only real fix if you want to share DLLs between different apps.
To add to the already excellent answers, you have a couple more choices:
The preferred solution(s) to this problem, supported since Windows XP, is to turn your dll's into a win32 assembly (They don't have to be .NET but the documentation on creating win32 assemblies with strong names is appallingly light so its easy to get confused and think this is a .NET only technology).
An assembly is noting more complicated than a folder (With the name of the assembly) containing the dlls and a .manifest (With the name of the assembly) that contains an assemblyIdentiy element, and a number of file nodes for each dll in the assembly.
Assembly based searching works even when dlls are statically linked!
The easiest option is to create unversioned assemblies and store them in the same folder as your .exe files (Assuming all your exe's are in a single folder).
If the exe's are in different folders, then there are two ways to access shared assemblies:
You can store your assemblies in a private alternate location if you expect your application to be used on Windows 7 and higher. Create a app.exe.config file for each of your exe's, and point a probing privatePath element to a common folder where you are storing the assemblies.
If you are ok with requiring administrative access to perform installs, (via MSI's) then you can deal with the appallingly bad documentation (well, absent documentation) that deals with giving your assemblies a strong name, and then store the assembly in WinSxS.
If you can't, or do not want to bundle your dlls as assemblies then this page covers dll search order
Using functions like SetDllDirectory are only going to help for dlls loaded dynamically at runtime (via LoadLibrary).
Dll search order used to be:
Directory containing the process exe
Current directory
various windows folders
PATH
Which you could have used to your advantage - launch each exe, setting the "current" directory to the folder containing the OSS dlls.
With the advent of SafeDllSearchMode the search order now is:
Directory containing the process exe
various windows folders
Current directory
PATH
Meaning theres now less control than ever :( - It goes even faster to the "untrusted" c:\windows & System32 folders.
Again, if the initial dll is being loaded via LoadLibrary, and its the dependent dll's that are the problem, LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag will cause the following search order (Assuming you pass a full path to LoadLibraryEx) :-
Directory part of the Dll path passed to LoadLibraryEx
various windows folders
Current directory
PATH
The directory from which the application loaded is normally the first directory searched when you load a DLL. You can, however, use SetDllDirectory to get the "alternate search order". In this case, the directory you specify to SetDllDirectory gets searched first.
There is also a SafeDllSearchMode that affects this to a degree. Turning it on excludes the current directory from the search.
Maybe just compile them to a static library?
Why not?
Also, the current directory, where the exe is activated from is searched before c:\windows.