There are two EventLogMessages.dll files,
C:\Windows\Microsoft.NET\Framework\v4.0.30319\EventLogMessages.dll
C:\Windows\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll
These files are not .NET files (they can't be dis-assembled with ILDasm). What are the differences in these two files?
I used 2.0 version of the file for VS2010. Is it safe to do that?
If not, why should I be using 4.0 version of it?
-Datte
There is no actual difference between them (except version info). The both dlls contain equal message tables, which are:
MESSAGETABLE
{
0, "%1"
1, "%1"
2, "%1"
3, "%1"
4, "%1"
.............
65535, "%1"
}
So, IMO, there are two different versions of those dll due to different versions of .Net framework, and if your app was built for target framework .Net 4 or higher (it's only my assumption) and there is logging to event log in your app, EventLogMessages.dll v.4.0.30319 will be used.
Related
I've created a patch with Advanced Installer by using an old (target image) msi and the new one (upgrade image). Inspecting MSP file I've discovered that it contains both modified and completely new files. The problem is that during the installation it installs only the "added" files. Existing files are ignored. I've already tried MSIEXEC switches like:
REINSTALL=ALL
REINSTALLMODE=sumo / aums / omus etc...
UPGRADE="Yes"
IS_MINOR_UPGRADE = "1"
..in different order and combinations (i.e. "REINSTALLMODE=aums REINSTALL=ALL"), so don't reply or comment just by telling me to try REINSTALLMODE=omus or something similar.
When creating a patch there is a set of rules that need to be followed, have you checked those? Breaking one of those can lead to unexpected behavior, such as the one you are now encountering.
To check for the rules you can start with a diff between the project files, as they are standard XML ones, and check for their product code, component GUIDs, etc... For example folder synchronization is a common problem encountered when a patch is created, as this changes the component GUIDs.
For some odd reason all the core components (exe, dlls) I wanted to update were set to "Do not register this component with Windows Installer".
I suppose this is some kind of project bug, because it's very old and was migrated through different Advanced Installer versions (7, 8 and 9).
Anyway, I was not able to update my application correctly even with a fixed patch. Windows Installer kept on asking me to browse to target image msi file (cached installer of the previous version).
However not all of my customers keep those files (usually this cached files are stored in %APPDATA% folder). So I found a workaround:
I've applied "Hash files" option in order to create a MsiFileHash table
I've packed my msp patch in a bootstrapper (exe file) that starts it with the TWICE with following command-line parameters:
first time:
"myPatch.msp" /n {150F6CE2-8C12-414B-9377-F087A62E6B67} REINSTALLMODE=c /qb
second time:
"myPatch.msp" /n {150F6CE2-8C12-414B-9377-F087A62E6B67} REINSTALLMODE=dep /qb
REINSTALLMODE=c switch forces file compare algorithm based on hashes, so it doesn't require the original setup sources anymore
REINSTALLMODE=dep restores all the other missing files, files with unknown or different (from target) version
I hope this workaround will be useful to people that use MSI/MSP authoring tools other than Advanced Installer
I am an InstallShield noob and I was just experimenting with a couple of features in InstallShield.
I have a basic MSI project (InstallShield 2010). I created 3 features in my project namely -
1) 32 bit
2) 64 bit
3) Common Files
All these features deliver the files to program Files folder which is the default install folder.
Each of these features contain 2 components -
1. a .txt file
2. and a registry key.
For the both the components under 64bit feature, I have set the 64bit component option to true
In the Setup Design for 32 bit feature I have set the release flag as "X86"
and for the 64 bit feature I have set the release flag as "X64"
Now I have configured 2 releases
1. X86 release - which contains 32 bit feature + common feature
2. X64 release - which contains the 64 bit feature + common feature
Now when I execute the 64 bit MSI, all my files are delivered to ProgramFiles x86 folder, instead of ProgramFiles Folder.
However I am able to see that the 64 bit registry is created properly under the HKLM\software hive and not under WOW6432Node
I have been slogging away at different options for almost a day now without any progress :(
Ensure your 64-bit release does both of the following:
Roots files under [ProgramFiles64Folder] instead of [ProgramFilesFolder], probably through an appropriate custom action to set directories
Uses a Template Summary of x64 instead of Intel (plus the same list of language codes)
Michael you did put me on the right path.
I still used the programFiles folder as my base installation directory and I created a directory custom action just after costfinalize, which checks for the target architecture of the end machine and sets the Installdir as either Program Files x86( for 32 bit install) and Program Files x64 for 64bit install.
Thanks :)
Uses a Template Summary of x64
Set 64 bit component to yes
I am trying to extract the file-contents of an InstallShield setup.exe-file. (My plan is to use it in a back-office tool, so this must be done programmatically without any user interactions.)
Is this possible?
(Initial research seems to indicate it will fail.)
If it is possible to have a generic solution, for all recent versions of InstallShield that would be best.
Otherwise, if a solution only works for some versions of InstallShield it would be a step on the way. (It would probably be possible to deduce which InstallShield version a setup.exe is by looking at version resources of the exe-file.
I found that some InstallShield versions support /b or /extract_all. However there is no good way of knowing, just launching the exe and hoping it will extract and terminate orderly rather then displaying GUI dialogs doesn't seem like a good solution. So I am therefore looking for a more stable way.
Ideas welcome.
There's no supported way to do this, but won't you have to examine the files related to each installer to figure out how to actually install them after extracting them? Assuming you can spend the time to figure out which command-line applies, here are some candidate parameters that normally allow you to extract an installation.
MSI Based (may not result in a usable image for an InstallScript MSI installation):
setup.exe /a /s /v"/qn TARGETDIR=\"choose-a-location\""
or, to also extract prerequisites (for versions where it works),
setup.exe /a"choose-another-location" /s /v"/qn TARGETDIR=\"choose-a-location\""
InstallScript based:
setup.exe /s /extract_all
Suite based (may not be obvious how to install the resulting files):
setup.exe /silent /stage_only ISRootStagePath="choose-a-location"
http://www.compdigitec.com/labs/files/isxunpack.exe
Usage: isxunpack.exe yourinstallshield.exe
It will extract in the same folder.
On Linux there is unshield, which worked well for me (even if the GUI includes custom deterrents like license key prompts). It is included in the repositories of all major distributions (arch, suse, debian- and fedora-based) and its source is available at https://github.com/twogood/unshield
Start with:
setup.exe /?
And you should see a dialog popup with some options displayed.
The free and open-source program called cabextract will list and extract the contents of not just .cab-files, but Macrovision's archives too:
% cabextract /tmp/QLWREL.EXE
Extracting cabinet: /tmp/QLWREL.EXE
extracting ikernel.dll
extracting IsProBENT.tlb
....
extracting IScript.dll
extracting iKernel.rgs
All done, no errors.
Still not knowing too much about .NET, I am tasked with converting a rather big .NET solution from VS2008 to VS2010. Part of it are a set of C++ projects (/clr), which I migrated to VS2010. I set their target framework to 2.0, because they are used in projects that are not to be converted right now.
After a lot of hassle I am at the point where the whole solution builds in VS2010, but for automated builds and tests I need to have the thing built using MSBuild, too, and that fails. The problem is that somewhere the /d1clr:nostdlib switch gets appended to the compiler command line, leading to a nasty error message:
error MSB6001: Invalid command line switch for "CL.exe". Illegal characters in path. [C:\blah\foo.vcxproj]
When I look at the command line emitted by MSBuild the only odd thing I see is that it ends with said switch: ...foo.cpp bar.cpp baz.cpp /d1clr:nostdlib
I suppose this switch fails because the older compiler invoked for .NET 2.0 stuff doesn't know how to deal with it?
Where would I start to look for where this switch gets appended? I don't see it on the project's property page's C/C++/Command Line option.
Are you sure you need to set the target framework to 2.0?
Can't a 2.0 project reference a 4.0 project (or whatever the converted project is)?
From poking around the MSBuild files, the command seems to be added because of these lines in Microsoft.CppBuild.targets (on my machine, located under C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0:
<ClCompile Condition="'#(ClCompile)' != '' and '$(CLRSupport)' != 'false' and '$(CLRSupport)' != ''">
<AdditionalUsingDirectories>$(TargetFrameworkDirectory);%(ClCompile.AdditionalUsingDirectories)</AdditionalUsingDirectories>
<AdditionalOptions Condition="('$(TargetFrameworkVersion)' == 'v3.5' or '$(TargetFrameworkVersion)' == 'v3.0' or '$(TargetFrameworkVersion)' == 'v2.0')">/d1clr:nostdlib %(ClCompile.AdditionalOptions)</AdditionalOptions>
<AdditionalOptions Condition="'$(TargetFrameworkVersion)' == 'v4.0'">/clr:nostdlib %(ClCompile.AdditionalOptions)</AdditionalOptions>
</ClCompile>
In other words, it is added simply because you set the target framework version to something other than 4.0. (If it had been set to 4.0, it would instead add the /clr:nostdlib flag)
I have no idea why it wouldn't work when invoked directly via MSBuild, though. Perhaps it uses a different compiler version (PATH or some other environment variable not set up correctly, perhaps?)
When building via Visual Studio, it also invokes MSBuild, so really, it shouldn't make any difference that you call MSBuild "directly", unless some part of the environment is set up differently. (or you're calling MSBuild with the wrong flags)
Of course there's nothing "magical" about these MSBuild files, so you can modify them, or edit your project to reference separate versions of them instead (which you've modified to not insert the flag). It is, if you ignore the XML clutter, just a general-purpose build system. It doesn't have any "built-in" understanding of VC++ projects, beyond what is specified in these XML files.
I have an asp.net mvc project and reference a dll to a class library. I would like the dll to appear in the bin folder of my asp.net mvc project (the latest version after building the asp.net project). This does not happen depite the dll's property 'copy local' being 'true'. Is this possible anyway?
Thanks.
C
If the class library project is in the same solution as your MVC project, you could set the build directory of the class library to be the bin of your MVC app.
This will help if you're not sure how
http://msdn.microsoft.com/en-us/library/ms165410(v=VS.90).aspx
If your setup precludes you from changing the output directory, another solution may be to set up a pre build step in the mvc app and use xcopy to copy the dll.
xcopy /y /r /i "$(SolutionDir)ClassLibrary\bin\myClassLibrary.dll" "$(TargetDir)"
if errorlevel 1 goto BuildEventFailed
Though, I'm a little curious why the dll isn't being copied automatically. Are you using any of the types in the class library explicitly; creating instances of, or inheriting from, or anything that would indicate to the compiler you do indeed need this dll? I think VS tries to be helpful and not copy binaries it feels are "useless"