I have 2 different solutions for nightly build compiling almost the same code.
I also have 2 different solutions compiling 2 different wix installers.
same *.dlls goes to different *.exe
The installers are outputing ICE03 Invalid language ID....
ICE03: Invalid Language Id; Table: File, Column: Language, Key(s): filAAED19CB2C0BBE304CDB8EB1AAF7473F
the language ID for both is 1033. and i don't want to suppress the ICE03 warning,
at first the installer error about *.xml files and *.pdb files so i removed them from the installer.
however now it outputs this error for *.png files which are my icons...
on my local machine both of the installers are building fine!
so i suspect the definition of the build...
has anyone come across this issue?
My solution for now is to suppress the ICE03 warning, it works.
however i don't like this solution
Related
I migrated my WIX project from V2 to V4 and then changed the namespace in the .WXS files
I replaced the below namespace
<Wix xmlns="http://schemas.microsoft.com/wix/2003/01/wi">
with
<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
Once the changes have been made when i run the build installer i am getting the below error:
error CNDL0199 : The Wix element has an incorrect namespace of
'http://schemas.microsoft.com/wix/2003/01/wi'. Please make the Wix element
look like the following: <Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
E:\Code\EMR\Wix\src\EMR_Registry_entries.wx
I replaced the new namespace but it is not reflecting. Once i run the build installer it is setting with the old namespace. I tried multiple times but it is always setting the old namespace.
Please help me to resolve the issue.
UPDATE: Question that came up from a second read of your question.
Source Control: "Once I run the build installer it is setting with the old namespace." - are you sure the build process doesn't
auto-magically 1) check the WiX source out of your source control system? Or 2) maybe it is doing some XML manipulation via the automation script?
WiX Version: Are you sure you are compiling with WiX 4? Maybe you are compiling with WiX 2 or WiX 3 unintentionally? Try hard coding the full path to the WiX binary in your build system - if you have one. Please see this (Sean is a WiX developer): Migrate Wix Project to version 4.0. Frankly I am not sure how well WiX handles multiple-version installations on the same box combined with migrated sources (identically named binaries of different versions - WiX 2, 3, 4 - globally applicable via the PATH variable? Not sure).
Visual Studio / Cmd.exe?: Are you compiling with Visual Studio or via the command line? (I am not quite sure reading your question). Maybe try via the command line (towards bottom) if you are using Visual Studio - or vice versa. Make sure you use the correct WiX binaries (in other words WiX 4).
Linked Files?: I don't have any WiX 2 sources to migrate, but I am wondering if you have several source files that are interconnected. Was that even possible in WiX 2? I can't remember. In either case, I would make sure you have updated all WiX source files that are pulled in during the build process. Please read the log carefully. Maybe try to compile them with Candle.exe directly using the command line (cmd.exe instead of Visual Studio) to see if the file compiles OK.
Source Files?: If it still does not work, please put the source file online so we can have a peek. Github.com for example. A quick look at the source (the real McCoy) goes a long way sometimes - and sometimes it doesn't help at all. Maybe give it a go. Redacted sources are just fine - encouraged even. Please pay close attention to sensitive data: How do I avoid distributing sensitive information in my MSI by accident? (and this also goes for published source files - obviously - not just the compiled MSI and its helper files - such as silent installation template batch files).
In summary: That became a lot of babble. Maybe first try to compile the migrated WiX source with the right WiX 4 binaries to
determine if that works or not. Then work backwards to figure out what
happens during the build process.
I am trying to build a program for x64, but I keep getting the following error messages:
C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(2554,5): error MSB4216: Could not run the "GenerateResource" task because MSBuild could not create or connect to a task host with runtime "CLR4" and architecture "x64". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe" exists and can be run.
C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(2575,7): error MSB4028: The "GenerateResource" task's outputs could not be retrieved from the "FilesWritten" parameter. Object does not match target type.
MSBuild.exe exists and can be run, so I don't know why I am getting these errors.
I am using Visual Basic in Visual Studio Professional 2013 (Update 4). I am not using any DLLs, all I am creating is a standalone .exe file.
I've tried searching, both here and on Google, but cannot find anything helpful. Then again, I have a tendency to overlook things, so the answer has probably been screaming in my face for the last hour. I apologise in advance if this turns out to be the case.
Any and all help is very much appreciated.
replace
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe
by
C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe
and try.it should do some difference.this occurs because the version on msBuild.exe has changed after update4 of vs2013.check for version differences..
also i suspect you are trying to build the solution in x86 architecture.if first solution doesnt work,go to the Build tab, change the Platform target from Any CPU" to "x86" and try. hope it helps.
I just encountered this exact same error in a multiple project VB solution when trying to start a debug instance of one project. By forcing a rebuild of that one project I was able to fix the issue and start the debug instance.
I solved this problem by opening the project in Visual Studio 2017, instead of 2015
When I run my TeamCity build with the only build step being of runner type Visual Studio (sln), I get the following error:
C:\TeamCity\buildAgent\work\4978ec6ee0ade5b4\Test\Code\Test.sln(2, 1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 2, position 1.
This is on a dedicated CI server running TeamCity Professional 8.1.1 (build 29939). There are several other successfully-running builds on this server.
The odd bit is that the same build runs successfully on TeamCity on my dev machine. I followed an answer to a similar question, and copied the specified folders across, but that didn't help.
I'm sure the project/solution file isn't invalid because in addition to the build running on my dev box, I have opened the solution in Visual Studio and built it there with no problems.
Any suggestions?
I just fixed this.
Look inside the Test.sln file for Project or EndProject tags that aren't closed. For us, the EndProject was missing and it broke on teamcity, but no issues in Visual Studio.
It seems the TeamCity error message will occur for any number of root causes. In my case the problem occurred because a line inside the GlobalSection(NestedProjects) section was referring to a project Guid which didn't relate to any project defined in the Solution file.
As with the previous post I didn't have any issues building in Visual Studio. I only got a more helpful error message that allowed me to discover what the real problem was when I built using msbuild.
See https://therightjoin.wordpress.com/2014/07/04/msb4025-the-project-file-could-not-be-loaded-data-at-the-root-level-is-invalid-error-when-building-ssdt-project-in-teamcity for another example, and where using msbuild helped identify the true problem.
In our case, it was a duplicate project reference in the solution file (caused by near simultaneous commits and an automatic merge).
In our situation the problem was specifying a ToolsVersion that was not installed on that machine. (14 which VS2015 has but VS2017 does not have by default)
In my case, after merging, in .sln file, it was a mismatch of lines under
GlobalSection(NestedProjects) = preSolution
{6B971E15-6B61-4AA8-9B93-9639C23269C3} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
{54D14F01-D576-4DE6-9404-D21AD0DC4916} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
... (was some extra entry here )
...
EndGlobalSection
section. In clear words, there were some extra lines added after merging. So, If you have merged, please compare two solution files manually. You can start with total line numbers in both files.
In another Case
We had a blank lines - so make sure any blank lines are removed!
Hope this helps some else too!
I got this same error with Jenkins. It turns out the root Jenkins folder was set to C:\Program Files (x86)\ and it didn't have write access to bin and obj directories.
Error:
error MSB4025: The project file could not be loaded. Data at the root level is invalid.
I launched cmd as Administrator and ran this:
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "C:\Program Files (x86)\Jenkins\workspace\BuildBI_1\Reports\Test\ReportsTests.sln" /t:Build /p:RunOctoPack=true
And that gave me clues about not being able to write to bin and obj.
This worked for me-
You can install Build Tools for Visual Studio 2017, make sure to select C++ tools, Windows 10 SDK and MSBuild and your set.
Use MSBuild to identify the underlying problem:
$> msbuild mysolution.sln
Gave me this beauty with the correct error line number:
If msbuild cannot be accessed like that from the command line / powershell, try to find the MSBuild.exe shipped with VisualStudio, e.g. C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\amd64\MSBuild.exe.
VisualStudio itself seems to be very "tolerant" against errors / inconsistencies in the solution file, so having it open in VS is no guarantee for the sln file being correct.
I fixed it by updating the solution file.
Another possible problem (and resolution): I had a stray unused solution file in my repo, pointing to who-knows-where, and the MSBUILD step in my Azure DevOps pipeline was set to **\*.sln.
I have seen many solutions for automating my InstallShield build, but I am having issues with each one. I am using InstallShield Professional 2013. Sorry for the lengthy question, but I am clueless on which direction to go to solve my issues.
1) IsCmdBld.exe - I have a script that runs and will build my installer. BUT, when the installer runs, I get an error message that says "The System Administrator has set policies to prevent this installation". I am not sure why this is happening, but I do not get the same error message if I build the installer through the designer. EDIT: Here is my command (%guid% is a Guid I generate to set the Product Code):
for /f %%i in ('"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\uuidgen.exe"') do set guid=%%i
"C:\Program Files (x86)\InstallShield\2013 SP1 SAB\System\ISCmdBld.exe" -p "MyInstaller.ism" -r SingleImage -y "1.0.0.13" -z ProductCode=%guid%
2) InstallShield Automation Interface - I have followed numerous examples and tutorials on this, but all end in the same result. When I call the following code:
var project = new ISWiAuto20.ISWiProject();
I get this error:
Unable to cast COM object of type 'System.__ComObject' to interface type
'ISWiAuto20.ISWiProject'. This operation failed because the QueryInterface call
on the COM component for the interface with IID '{872D23A7-C18D-468C-895D-1CF027E4FBB1}'
failed due to the following error: Library not registered.
(Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)).
3) MsBuild.exe - Running MsBuild on my InstallShield project file yields this error:
error NSB4025: The project file could not be loaded. Invalid character in the
given encoding. Line 1, position 1
The choice between these approaches (when they all work) largely depends on the build system you are trying to integrate with. If you're using a batch or makefile approach, IsCmdBld.exe is probably the easiest starting point. If you're using Visual Studio and TFS or MSBuild, you'll probably have more luck there, as it will report errors in a way the build system can understand. (Other than that, they're fundamentally similar.) If you need to make tweaks to the project before you build it, the automation layer can either augment or replace the other approaches.
But in your case you say they all don't work. What have you done to diagnose why? Here are the first steps I'd take for each of those symptoms:
IsCmdBuild built setups yielding an error that the IDE-build ones do not. First identify what the problem really is. Look in a verbose log for more information. Build both ways with the .msi available and compare the results with MsiDiff. Make sure you've tested elevated. Depending on what you find, it may be something to address in the project, the build process, or a bug in InstallShield.
Automation Interface yields TYPE_E_LIBNOTREGISTERED. First off, if this is the IDE machine, consider repairing the installation. If it's a standalone-build machine, ditto. If it's a standalone-build machine that didn't use the installation, you should, or at least you should ensure the dependencies are present and that the automation interface is registered. Secondly, as Christopher Painter noted, InstallShield is a 32-bit product so it must be invoked from a 32-bit context. If you're calling, say, CScript to run a .vbs file, make sure you're using C:\Windows\SysWow64\CScript.exe.
MSBuild NSB4025. The comment from stijn is largely correct - you can't call MSBuild on the .ism file (while it can be xml instead of binary, it's not MSBuild-compatible). However you can create a .isproj file that can work correctly. Save the project in Visual Studio, or copy <InstallShield>\Support\0409\MSBuild.xml to (ProjectName).isproj and tweak its contents; call MSBuild on the resulting .isproj file. Odds are strong this will have approximately the same results as IsCmdBuild, as the build portion is largely shared.
Using MSBuild doesn't follow the exact order of the Project files specified in the solution .sln file.
The best option is to use devenv.exe
And sometimes, devenv doesn't return exact return status, so I kept an exe to scan the log file for the success code.
https://devopsdiaryblog.wordpress.com/2017/12/20/devenv-return-code-issue/
And for iscmdbuild.exe, better to use commandline as it is the suggested one from flexera.
I had an app A for which I created an installer A1. This has been in use for many months.
We now realized that AI used to package some files - d1,d2,d3 which are not needed.
Therefore we removed them from our project and created an installer A2 which does not package the above mentioned unwanted files. (atleast thats what we expect)
Things are ok when I use this installer the usual way...but when I use this for a silent install, I get the following error:
Error 1334. The file d1 cannot be installed because the file cannot be found in cabinet file 'myMedia1.cab'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.
I googled this and saw that people usually encounter this whn u release a patch or some installer release where some files are removed or moved around.
Apparently, msiexec tries to reference some cached version of these variables and since it still looks for the missing files in the new installer, install fails.
Is there a way to tackle this? - like some way to have msiexec use just the .msi file I provide in the input rather some cached version.
Thanks...
It sounds like you could receive this error if you haven't updated the PackageCode, ProductCode, or UpgradeCode for your A2 installer. If A1 is installed, and then A2 runs with the same PackageCode, ProductCode, and UpgradeCode the system thinks you are running the A1 installer again and will look for the cached A1 msi under C:\windows\installer.
For anyone else like me that is experiencing the same problem (Error 1334) when building a Setup project and didn't find any explanations or solutions, here's a thread that solved my problem:
https://www.itninja.com/question/1334-error-tried-just-about-everything-i-can-think-of-anyone-know-of-some-obscure-causes
Basically, the solution to the problem is to “touch” all the files referenced in the Setup project (that is, all the dependencies - DLLs and all else). You can find the list and path of all the files in the build output, on lines like these:
2> Copying file from "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Threading.dll" to "C:\Path\To\Your\Project\bin\Debug\System.Threading.dll".
To “touch” the files, you may use this technique or you may use some third-party file manager like Total Commander. You'll just need to run as administrator / accept UAC warning, because some files are in system folders.
EDIT: in my case, the problem with the Setup project began after updating some NuGet packages used by the main project.
P.S.: although I'm not using WiX, but Microsoft Visual Studio Installer Projects, the symptom was the same, so I hope this answer will be helpful for someone.