Good day everyone,
While working with Wix I am having a hard time solving the following error message:
Prompt for source of container: WixAttachedContainer
The scenario:
We have a setup project with the default Wix template that acts as a bundle for several packages, called MyBundle.exe.
We have a managed bootstrapper application wix exe with WPF and C# that acts as a standalone installer, but this needs to be included in the bundle stated above, called MyApp.exe.
MyApp.exe gets installed correctly when installing MyBundle.exe.
When uninstalling MyBundle.exe and having a DetectCondition to uninstall MyApp.exe. MyApp.exe gets removed correctly.
The Problem:
There is a scenario where MyBundle.exe will get removed but has to leave MyApp.exe installed behind.
After removing MyBundle.exe, and trying to remove MyApp.exe I get the following error in the log:
Prompt for source of container: WixAttachedContainer, path: "Path_To_EXE"
If I install MyApp.exe as a standalone and uninstall it, everything works just fine.
If I install MyBundle.exe (MyApp.exe included in MyBundle.exe) and uninstall MyApp.exe before removing MyBundle.exe, this works fine as well.
I have read the logs of MyApp.exe where the error comes up and I found that MyApp.exe is trying to reach the cache folder of MyBundle.exe
Prompt for source of container: WixAttachedContainer, path: C:\ProgramData\Package Cache\{Bundle_GUID}\Dependencies\MyApp.exe
But at this point, that folder is no more on the system.
The configuration of the ExePackage in MyBundle.exe is as follows:
<ExePackage Id="MyApp_Package"
Description="MyApp Package"
DisplayName="MyApp Package"
SourceFile="My_Path_To_Package"
Compressed="yes"
Permanent="yes"
PerMachine="yes"
Vital="yes"
Cache="yes">
</ExePackage>
I have tried several combinations of the tags Permanent, Cache, but still to no effect.
I have tried already hooking up to the ResolveSource method inside the C# code on MyApp.exe following instructions like this:
Managed Bootstrapper Application "Failed to resolve source for file" but to no success.
Can any of you point me in the correct direction?
UPDATE: Both MyBundle.exe and MyApp.exe, as well as the msi included are signed using signtool.
Thanks.
Take a look at "insignia"
https://wixtoolset.org/documentation/manual/v3/overview/insignia.html
It's not enough to just use signtool to sign the boostrapper EXE. The bundle inside it needs to be signed also.
Related
How is this possible?
I installed .net sdk 6.0.405: dotnet-sdk-6.0.405-win-x64.exe
I can in windows terminal and power shell run: dotnet --version: 6.0.405 ✅
I CAN ALSO IN VSCODE IN ITS BUILTIN TERMINAL, run: dotnet --version: 6.0.405 ✅✅
But in the OUTPUT tab, choosing OmniSharp Log from the dropdown, it says:
[ERROR] A .NET 6 SDK for x86_64 was not found. Please install the latest x86_64 SDK from ...
I switched vscode explorer settings to use external terminal.
And this terminal setting to command prompt:
Terminal › Integrated › Default Profile: Windows
The default profile used on Windows. This setting will currently be ignored if either terminal.integrated.shell.windows or terminal.integrated.shellArgs.windows are set.
I have dotnet in the PATH (and it works in terminals and in vscode's terminal)
I restarted vscode, AND REINSTALLED the dotnettools "C# for Visual Studio Code (powered by OmniSharp)" extension. I went to the online store and from the right column under Resources I downloaded the ms-dotnettools.csharp-1.25.2#win32-x64.vsix to make sure I get the right one. And restarted vscode.
I tried this setting:
Omnisharp: Dotnet Path
Specified the path to a dotnet installation to use when "useModernNet" is set to true, instead of the default system one. This only influences the dotnet installation to use for hosting Omnisharp itself. Example: "/home/username/mycustomdotnetdirectory".
C:/Program Files/dotnet/sdk/6.0.405
And this setting:
Omnisharp: Sdk Path
Specifies the path to a .NET SDK installation to use for project loading instead of the highest version installed. Applies when "useModernNet" is set to true. Example: /home/username/dotnet/sdks/6.0.300.
C:/Program Files/dotnet/sdk/6.0.405
And restarted vscode. And now it says:
[ERROR] Error: Command failed: dotnet.exe --version
'dotnet.exe' is not recognized as an internal or external command,
operable program or batch file.
What? W H A T? lol
What could be wrong? Why isn't it saying where it expected to find it and what to do to locate it? Is there a setting to specify the dotnet.exe path to this C# extension? Does it need always-on internet or something? Does it have DRM? Does it need Edge installed? Wtf?🙂
🙃😭 I just need intellisense; and I've wasted 2h, on only microsoft-owned products.
#Microsoft 0/5 stars
Still don't know why it happens, but here's how to solve it:
The problem was from this: I like to keep all my visual studio code extensions as .vsix files locally in folders so I can remember and get them easily & offline. Sensible enough choice, and I had the correct ms-dotnettools.csharp-1.25.2#win32-x64.vsix for my platform.
But in VSCode, when I install this particular extension via VSIX, even though it succeeds, it can't find .net. If you instead install the extension "normally", ie via vscode's own download, it seems vscode does some extra configuration steps while installing, and probably sets the .net paths correctly or something. Because now it works.
So TL;DR: don't install ms-dotnettools.csharp via vsix, it seems bugged. 😶
Would love to see an answer explaining what's wrong / how to actually do via vsix; but I don't have any more time to debug this rn.
I am writing a multi-platform c# command line application using .NET Core 3.1 that will need to work as a single executable. I am using Visual Studio 2019 (16.5.4). My OS is Windows 10.0.18363.778 and I intentionally did NOT install Powershell 7. I tested this first bit on my Windows and WSL Ubuntu and it worked until I added Powershell SDK 7. After I installed Microsoft.Powershell.SDK 7.0.0 and when Ì set the project file as follows, everything runs nicely and I can validate I am using PS7 and not Windows PS.
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>
However, when I add the runtimeIdentifier in PropertyGroup:
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
Build successfully completes without errors. However when I ran (both debuging or standalone) and application hits Powershell.Invoke, it throws a FileNotFound Exception with message:
"Could not load file or assembly 'Microsoft.Management.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified."
1) What am I missing to get all depdendencies in the executable directory?
2) When I add the following to create the single executable
<PublishSingleFile>true</PublishSingleFile>
<UseAppHost>true</UseAppHost>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
It does not get created. I get the executable if I use:
"dotnet publish -r win-x64 -c Debug"
but nothing happens when I run it. (This step used to work fine before PS7)
Is there anthing else I need to do to get the single executable running?
I did some research and figured the following:
Answer 1: There is no Runtime identifer specific Microsoft.Management.Infrastructure.dll files in the runtimes directory. Either Powershell SDK does not support all runtime identifers or its a bug. I will take it to github.
Answer 2: Running the single Executable file is misleading. My expected result was creation of a log file which is created in the application directory. I figured that when the single exe is run, it actually unzips ALL the files to the temp directory and runs the application from there (not the single executable) and hence the log file is not created where the single file executabe is.
To resolve your problem, you have to add this reference to your project. It take me 1 day to found this.
<PackageReference Include="NETStandard.Library" Version="1.6.1" />
My current process is approximatly:
I start with a Disk image of Window 7 x64 with only:
Unity 4.3.3f1, Located 'C:\Program Files(x86)\Unity'.
The adt-bundle-windows-x86-20131030. 'C:\Users\Will\adt...'.
The Java 32bit runtime 1.7.0_51-b13, 'C:\Program Files(x86)\Java'.
'C:\Program Files(x86)\Java\jr7\bin;' is manually added to my 'Path' Environment Varible.
As it is I can cleanly deploy Android projects, however I want to use the official Facebook SDK plugin. At this point on my first attempt to install the plugin I dropped it into a project as per the official 'Getting Started' tutorial and this is where I get a bit lost. Even though there is no mention of it in the 'Getting Started' tutorial I find that OpenSSL is a dependancy of the SDK.
So I install the OpenSSL binary 'Win32OpenSSL-1_0_1f' to 'C:\Program Files(x86)\OpenSSL-Win32' and when the plugin still can't find it I add 'C:\Program Files(x86)\OpenSSL-Win32\bin;' to my 'Path' Environment Variable.
At this point The plugin's 'Debug Key Hash' starts working and I naievly assume that everything is correct, However; When I attempt to deploy a build I recieve the following error:
Error building Player: Win32Exception: ApplicationName='C:\Program Files (x86)\Java\jre7\bin\javac.exe', CommandLine='-bootclasspath "C:/Users/Will/adt-bundle-windows-x86-20131030/adt-bundle-windows-x86-20131030/sdk/platforms/android-19\android.jar" -d "C:\Users\Will\Documents\Unity Projects\test\Temp\StagingArea\bin\classes" -source 1.6 -target 1.6 -encoding ascii "com\DefaultCompany\test\R.java" "com\facebook\android\R.java"', CurrentDirectory='C:\Users\Will\Documents\Unity Projects\test\Temp\StagingArea\gen'
and the build process is halted.
Could anyone help explain where I am going wrong and to get this plugin to behave?
I had the exact same issue - I've solved it by deleting the JAVA_HOME environment variable that pointed to a directory containing JRE (instead of JDK). You also seem to only have JRE installed and the javac.exe file is not part of that package. Alternatively, point JAVA_HOME to the directory on your machine that does have JDK (and javac.exe) installed.
I have installed dotless via Package Manager in VS2012 in to an existing mixed C# solution (Class libraries and MVC2 apps), however now when I build it (F5) I get the following two errors:
The command ""C:\#GitRepos\EBS\SolutionFiles\.nuget\nuget.exe" install
"C:\#GitRepos\EBS\\packages.config" -source "" -o
"C:\#GitRepos\EBS\SolutionFiles\packages"" exited with code -1.
and
The system cannot find the path specified.
After adding dotless to the solution a ".nuget" folder with "NuGet.exe and "NuGet.targets" has been added.
I have also tried adding dotless to a new MVC2 project and other than having to add a mime type to the web.config it all works well. There isn't however a ".nuget" folder.
I also noticed that the same happens if I create a new NServiceBus solution (after installing it). The paths in the message change but the error is the same.
If I take
"C:\#GitRepos\EBS\SolutionFiles\.nuget\nuget.exe" install
"C:\#GitRepos\EBS\\packages.config" -source "" -o
"C:\#GitRepos\EBS\SolutionFiles\packages"
and run it via a command prompt then I get:
All packages listed in packages.config are already installed.
So after giving up on this and then a few days later looking in to it again, I found the answer. I came across david-martos.blogspot.co.uk. After opening my command prompt and finding it also said "The system cannot find the path specified" I went looking in the registry. I found in "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" that there was an AutoRun key for "c:\ansi140\x64\ansicon.exe -p ". After deleting this and trying one of my NserviceBus solutions again I found it built fine. I hope this helps others.
Here is a direct link to David Martos post.
This was also likely a nuget package restore consent that you had to set. http://blog.nuget.org/20120518/package-restore-and-consent.html
For anyone who wants to permanently have the consent accepted, take a look at installing http://nuget.org/packages/NuGetEnablePackageRestore - it will be accepted on all machines automatically.
I solved this problem by opening up the Package Manager Console and clicking on the "Restore" button on the warning that popped up. Here's a pick of what it looked like. This is similar to the other solutions, but from a different angle.
Just execute the command below from NuGet Package Manager Console. It worked for me:
PM> Install-Package NuGetEnablePackageRestore
I had the same error:
"The command "" exited with code -1." and "The system cannot find the path specified."
I tested all the possible solutions I found and nothing worked, at the end what I did was take the NuGet.exe from another project and replace it in the project inside the .nuget folder that was generating the error and is working now.
For me, I had accidentally deleted the NuGet.Config file from the root of my project directory. Fortunately, I could restore it with source control.
Here's the content of my file if anyone have done the same mistake as me and doesn't have a backup:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositorypath" value="NuGet Packages" />
<add key="globalPackagesFolder" value="NuGet Packages" />
</config>
<packageRestore>
<add key="enabled" value="True" />
</packageRestore>
</configuration>
I have a .net application built on .net framework 3.5, I am trying to build this application on Jenkins CI server. I've added MSBuild plugin and and have added path to the .exe file of 2.0, 3.5 and 4.0 versions of MSBuild. But my building processes are failing by showing the below error message.
Path To MSBuild.exe: msbuild.exe
Executing command: cmd.exe /C msbuild.exe Neo.sln && exit %%ERRORLEVEL%%
[Test project] $ cmd.exe /C msbuild.exe Neo.sln && exit %%ERRORLEVEL%%
'msbuild.exe' is not recognized as an internal or external command,
operable program or batch file.
Build step 'Build a Visual Studio project or solution using MSBuild.' marked uild as failure
Finished: FAILURE
Could anyone plz help me out..??
To make the MSBuild plugin work, you need to configure the plugin in the Jenkins management screen.
NOTE: in the newer Jenkins versions you find the MSBuild configuration in the Global Tool Configuration:
Note the "Name" field, where I've called this particular configuration v4.0.30319. You could call it anything you like, but ideally the name will somehow refer to the version.
You'll need to refer to this name later in the Jenkins PROJECT that's failing.
Note: The yellow warning implies that the Path to MSBuild field should be populated with a directory name rather than a file name. In practice you do need to enter the filename here too (ie. msbuild.exe) or the build step will fail.
In the Jenkins project that's failing, go to the MSBuild build step.
The first field in the build step is "MSBuild Version". If you created the build step before configuring any MSBuild versions, the value here will be (default).
After configuring one or more MSBuild versions, the drop down will be populated with the available configurations. Select the one you require.
You can see here that I've now selected the named configuration that matches the installation above.
Jenkins | Manage Jenkins | Configure System
scroll down to the MSBuild section and click MSBuild installations
define the full path to msbuild.exe, on my system I have 3.5 and v4.0.30319
Note - specify the path to 32-bit tools even on a 64-bit system, otherwise you might get an error message:
Building Windows Phone application using MSBuild 64 bit is not supported.
So in Jenkins - it could be for example:
Name: Version 3.5
Path: C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
Name: Version 4.0
Path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSbuild.exe
I think you should set an absolute path for "msbuild.exe" in your Jenkins configuration,
for example:
C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe
You can also add the path where the msbuild.exe is, to the PATH system environment variable of the node (or nodes) that is running that specific job.
You could try executing the
%comspec% /k ""c:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86
command, which will temporarily update your environment path variables to reflect the VS2010 build environment. Execute this before you call MSBUILD and see what happens. I use this in my own build scripts with no issues.
Side note; it's very likely counterproductive to have multiple versions of MSBUILD on your PATH. Concentrate on getting one version working and go from there.