I am trying to convert to UWP my desktop application Computator.NET (written in WinForms) which is using InstallShield for it's installer but DAC does not seem to find executable. It looks like it thinks that exe file is some temporary installer file. Log from the process is below:
WARNING: DesktopAppConverter : warning 'W_PACKAGE_DEPENDENCY_ADDED': A
dependency on framework package 'Microsoft.VCLibs.140.00.UWPDesktop'
was added to the AppxManifest.xml. See
'http://go.microsoft.com/fwlink/?LinkId=821959' for guidance on
installing the package prior to local deployment. Otherwise, if this
is in error, remove the corresponding entry from Dependencies in the
AppxManifest.xml before packaging and deploying your application.
WARNING: DesktopAppConverter : warning 'W_DISCOVERED_EXE_NOT_FOUND':
Discovered shortcut indicates the app executable should be
'\WINDOWS\Installer{FA089B43-0451-420A-968B-DCC3C55644C7}_8C37B49DBB16422C8EF917F2AEA02293.exe',
but this file cannot be found. WARNING: DesktopAppConverter : warning
'W_DISCOVERED_EXE_NOT_FOUND': Discovered shortcut indicates the app
executable should be
'\WINDOWS\Installer{FA089B43-0451-420A-968B-DCC3C55644C7}_A9A8E5CA913F4E1EB7F6ACDB86DAFB8B.exe',
but this file cannot be found. WARNING: DesktopAppConverter : warning
'W_DISCOVERED_EXE_NOT_FOUND': Discovered shortcut indicates the app
executable should be '\Windows\SysWOW64\msiexec.exe', but this file
cannot be found. WARNING: DesktopAppConverter : warning
'W_EXE_NOT_DISCOVERED': The application executable could not be
determined from any shortcut. MakeAppx will fail until you fix the
Application Executable property in the AppxManifest.xml WARNING:
DesktopAppConverter : warning 'W_INSTALL_PATH_NOT_DISCOVERED':
Converter could not determine your application's install path. Please
use the -AppInstallPath parameter to move app binaries outside of VFS.
WARNING: DesktopAppConverter : warning
'W_CANNOT_MAKEAPPX_WITHOUT_EXE': Unable to create appx package without
setting the 'Application Executable' property in the AppxManifest.xml.
Please set the 'Application Executable' property in the
AppxManifest.xml before calling makeappx manually. Warning Summary:
W_PACKAGE_DEPENDENCY_ADDED A dependency on framework package
'Microsoft.VCLibs.140.00.UWPDesktop' was added to the
AppxManifest.xml. See 'http://go.microsoft.com/fwlink/?LinkId=821959'
for guidance on installing the package prior to local deployment.
Otherwise, if this is in error, remove the corresponding entry from
Dependencies in the AppxManifest.xml before packaging and deploying
your application.
W_DISCOVERED_EXE_NOT_FOUND Discovered shortcut indicates the app
executable should be
'\WINDOWS\Installer{FA089B43-0451-420A-968B-DCC3C55644C7}_8C37B49DBB16422C8EF917F2AEA02293.exe',
but this file cannot be found.
W_DISCOVERED_EXE_NOT_FOUND Discovered shortcut indicates the app
executable should be
'\WINDOWS\Installer{FA089B43-0451-420A-968B-DCC3C55644C7}_A9A8E5CA913F4E1EB7F6ACDB86DAFB8B.exe',
but this file cannot be found.
W_DISCOVERED_EXE_NOT_FOUND Discovered shortcut indicates the app
executable should be '\Windows\SysWOW64\msiexec.exe', but this file
cannot be found.
W_EXE_NOT_DISCOVERED The application executable could not be
determined from any shortcut. MakeAppx will fail until you fix the
Application Executable property in the AppxManifest.xml
W_INSTALL_PATH_NOT_DISCOVERED Converter could not determine your
application's install path. Please use the -AppInstallPath parameter
to move app binaries outside of VFS.
W_CANNOT_MAKEAPPX_WITHOUT_EXE Unable to create appx package without
setting the 'Application Executable' property in the AppxManifest.xml.
Please set the 'Application Executable' property in the
AppxManifest.xml before calling makeappx manually.
I am runing Dekstop App Converter using fairly simple command:
DesktopAppConverter.exe -Installer C:\Computator.NET\Computator.NET.Installer.v2.1.0.beta.exe -InstallerArguments "/S" -Destination C:\Computator.NET\Appx -PackageName "Computator.NET" -Publisher "CN=Pawel Troka" -Version 2.1.0.0 -MakeAppx
It seems like this issue is because of the way InstallShield installer is working.
Fortunetely there is an easy way to resolve this - we need to pass path to executable, just like it -AppExecutable "path_to_your_exe_file_after_installation"
So my final command looked like this:
DesktopAppConverter.exe -Installer
C:\Computator.NET\Computator.NET.Installer.v2.1.0.beta.exe
-InstallerArguments "/S" -Destination C:\Computator.NET\Appx -PackageName "Computator.NET" -Publisher "CN=Pawel Troka" -Version 2.1.0.0 -MakeAppx -AppExecutable "C:\Program Files (x86)\Computator.NET\Computator.NET.exe" -Sign
Note that I also added -MakeAppx and -Sign arguments, this is because I wanted it to be ready for testing - just needed to install certificate auto-generated.cer to Trusted Root Certification Authorities after conversion and my appx was ready to be installed and tested on my developer machine.
This tutorial was really helpful during the process and also this article helped me a bit.
Related
This is pretty easy to replicate but also code here:
https://github.com/dominicshaw/dotnet-publish-error
create an empty wpf project using .NET7
create a publish profile for ClickOnce
publish via command line (not visual studio)
Publish profile is almost totally standard (view here)
Command line from project directory:
dotnet publish PublishError.csproj -p:PublishProfile=ClickOnceProfile
Subsequent error:
MSBuild version 17.4.0+18d5aef85 for .NET
Determining projects to restore...
All projects are up-to-date for restore.
C:\Program Files\dotnet\sdk\7.0.100\Microsoft.Common.CurrentVersion.targets(4149,5): error MSB4062: The "Microsoft.Build.Tasks.RequiresFr
amework35SP1Assembly" task could not be loaded from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKey
Token=b03f5f7f11d50a3a. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, a
nd that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\Users\shawd\source\repos\PublishError\Publi
shError\PublishError.csproj]
I have the latest SDKs installed and VS2022 up to date. This only happens via command line - I am able to publish from Visual Studio (I am setting up devops, so require command line).
This happens regardless of adding nuget package for Microsoft.Build.Tasks.Core. Note however nuget package v15.1.0.0 is not available - I have tried 15.1.548 and the latest instead.
Totally at a loss! Any ideas very welcome.
Thanks vm
During the tests with your project and files, I finally managed to publish it successfully with the command dotnet publish PublishError.csproj -p:PublishProfile=FolderProfile.
Here is the document for dotnet publish, as is referred,
The preceding example uses the FolderProfile.pubxml file that is found
in the <project_folder>/Properties/PublishProfiles folder. If you
specify a path and file extension when setting the PublishProfile
property, they are ignored. MSBuild by default looks in the
Properties/PublishProfiles folder and assumes the pubxml file
extension.
And I also succeeded with dotnet publish with your project.
==============================
update on 11/19
So I suppose that the issue is resulted from your definition for -p:PublishProfile=ClickOnceProfile,it will change the path where this command would search for the publish file
A partial answer as my workaround for anyone struggling with a similar problem:
I have found it impossible to do this with the dotnet cli but I can do it with MSBuild if I specifically target 17.4 (VS2022). By default, my Azure DevOps Server 2020 capability is the 2019 MSBuild (15.X), so I have to be explicit:
"C:\Program Files\Microsoft Visual Studio\2022\Professional\Msbuild\Current\Bin\MSBuild.exe" /restore /Verbosity:m /t:Publish /p:RuntimeIdentifier=win-x64 /p:configuration=Release /p:PublishProfile=ClickOnceProfile
This works - so in my pipeline I have created a batch file which runs this, then I copy the files to my ClickOnce location.
Not ideal, but a working pipeline.
Interesting side note - this dotnet cli command which should be idenitical (and indeed uses the correct 17.4 MSBuild) - does not work (with the same error):
dotnet msbuild -target:Publish -property:RuntimeIdentifiers=win-x64;Configuration=Release;PublishProfile=ClickOnceProfile
Im trying to start virgo server with vsphere sdk version 6.7 in my local machine and getting this error.
λ startup.bat
WARNING: jmxPermissions.vbs did not update the permissions of \vSphere Client SDK\html-client-sdk-6.7.0-8170180\vsphere-ui\server\configuration\org.eclipse.virgo.kernel.jmxremote.access.properties. Check the file has the correct permissions.
'Client' is not recognized as an internal or external command,
operable program or batch file.
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
Error: Could not find or load main class Client
The issue is that you have deployed the SDK on a Windows path with spaces - startup.bat thinks " Client SDK\html-client-sdk-6.7.0-8170180\vsphere-ui\server\" is a command line argument.
The simple fix is to move the SDK to a location without any spaces.
Kudos goes to my colleague Alex Marinov (https://www.linkedin.com/in/aleksandar-marinov/) for spotting this.
I'd like to schedule a KNIME workflow. The workflow does its job very good as long as I start it from the KNIME GUI application. When I execute the same workflow via command line, java complains that com.microsoft.sqlserver.jdbc.SQLServerDriver
could not be found (ClassNotFoundException).
I invoke it via:
"D:\Progamme\KNIME\knime.exe" -nosplash -application -consoleLog org.knime.product.KNIME_BATCH_APPLICATION -preferences="absolutepathto\preferences.epf" -workflowDir="absolutepathto\workflow"
Since the error message signals missing content in the java CLASSPATH I also tried to add the parameters
-vmargs -classpath .;"absolutepathto/sqljdbc42.jar"
But still I earn a java slap, pointing to the same error...
I also tried to run the command from within the knime.exe's directory and I also tried to add the JAR file to Preferences -> Java -> Build Path -> Classpath Variable / User Libraries (referenced via the -preference argument). But that had no effect.
Did anybody face the same problems? Maybe with other third party JARs?
It is all about a Database connector that is configured like this:
Does the integrated security maybe force a misleading error?
System spec: KNIME 3.2.2 on Windows Server 2008 R2
Update - extract from preferences file
/configuration/org.eclipse.core.net/org.eclipse.core.net.hasMigrated=true
/configuration/org.eclipse.ui.ide/MAX_RECENT_WORKSPACES=10
/configuration/org.eclipse.ui.ide/RECENT_WORKSPACES=<list of some workspaces>
/configuration/org.eclipse.ui.ide/RECENT_WORKSPACES_PROTOCOL=3
/configuration/org.eclipse.ui.ide/SHOW_RECENT_WORKSPACES=false
/configuration/org.eclipse.ui.ide/SHOW_WORKSPACE_SELECTION_DIALOG=true
Is there maybe a problem due to the fact that it is a shared KNIME instance among several users and the command line execution does not know which workspace has to be chosen? Is the workspace somehow needed and why?
Partial Solution:
I finally managed it but I don't know exactly why it works now. What I did was to load a fresh portable version of KNIME and ran the same commands only changing the executable path to the new portable version. Before that I started the portable version once to set the workspace directory and register the database driver in preferences dialog and .ini file, nothing else, same configuration so far as the shared KNIME instance. What I am really wondering abpout is that from now on the commands are also working with the shared KNIME instance. I really don't know what caused the change that let KNIME find the driver class.
Info
Because I encountered a few more problems within shared environment in KNIME command line mode, that led to undeterministic execution results, I wrote a little .NET library. This gives me more flexibility/control over the workflow execution (which returncodes and error messages occured and so on). You can find it here if you're interested: KnimeNet
I took a very minimal approach:
cd "C:\Program Files\KNIME"
.\knime -nosplash -noexit -consoleLog -reset -application org.knime.product.KNIME_BATCH_APPLICATION -workflowFile="D:\Work\Knime Workflows\Output\CMD_Test.knwf" -preferences="D:\Work\Knime Workflows\Output\CMD_Test.epf"
We have a VB.Net Winforms (x86) application that uses the freely redistributable version of Crystal Reports. Although the application works fine on my test machine, when installing on a client's machine and trying to print a report from the application, the error: The system cannot find the file specified. File name: 'CrystalDecisions.CrystalReports.Engine ... is displayed.
The inno-setup includes the CR redistributable "CRRedist2008_x86.msi" which was installed by the client during the installation. (We also tried running the "CRRedist2008_x64.msi" but received an "unsupported processor type" error).
I have read about Merge Modules that are prerequisites for .NET 1/2 (VS 2002/2005), but cannot find any useful information related to .NET 3.5 and am wondering if these files are still required and how to package and deploy them if they are in fact needed.
Any guidance on how to resolve this installation issue is much appreciated.
Edit
The Inno-Setup contains the following command that checks to see if CR is installed and if not the MSI is launched from the final setup form:
[Run]
Filename: "{app}\CRRedist2008_x86.msi"; Description: "Crystal Reports"; Flags: nowait postinstall skipifsilent; Check: EnsureCrystalReports105Installed();
The problem is that you are not actually executing the MSI file. You can see this by running your installer with /LOG and reviewing the resulting log file.
This is because MSI files cannot be directly executed -- they're data files, not programs.
To resolve this, you need to run msiexec instead, passing the MSI file as a parameter; eg.
[Run]
Filename: {sys}\msiexec.exe; Parameters: "/i ""{app}\CRRedist2008_x86.msi"""; ...
You should review the command line parameters accepted by msiexec and properties accepted by the MSI file to see if you want to do something different, eg. running the install silently instead of interactively.
Also, running it as postinstall is fine if this component is optional for your application and it can gracefully handle it not being installed. If this is not the case then you should treat it as a prerequisite instead and always install it via PrepareToInstall.
I am unable to build my Web Application (not Web Site) in our build environement. We use DMAKE in our build environment (this unfortunately is non negotiable, therefore using MSBUILD is not permitted ) and when invoking the asp.net precompiler through
C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_compiler -d -nologo -p Site -f -fixednames -errorstack -v / Debug
We get the following error
error ASPPARSE: Could not load type 'X.Y.Admin.Site.Global
If I compile from the ide it is successful. If i then compile with aspnet_compilier it is successful. So i only get a successful compile with aspnet_compiler when the target dll i am trying to compile is in the bin of the web application i am compiling.
I keep running into postings that talk about solutions using MSBUILD which unfortunately I cant try.
Any help would be appreciated
We had the same problem on our web application:
error ASPPARSE: Could not load type '...'
The problem was that we had the file on disk (on the project folder) but it wasn't included in our application project (in the .csproj file). We solved the problem by including the file in the project :)
I ran into a similar problem using NANT. The trick was to compile the web applications code files into a dll then include that when using aspnet_compiler.
use the command line compiler,either csc.exe (c#) or vbc.exe (visual basic), to compile your web application with an output of type library. This will create a dll that you can use in your aspnet_compiler task
Have you tried specifying the path using -p? Sounds to me like it can't find that type / assembly.
http://msdn.microsoft.com/en-us/library/ms229863(VS.80).aspx
For web applications, you have to build the .vb files into a dll and put that in the bin folder before you run the aspnet compiler. Check the output window in visual studio and you'll see the command line for the VB compiler. Run that first before you run the aspnet compiler, and the asp pages should be able to find the missing types.
This problem was resolved for me by simply deleting all bin and obj folders. Seems like they were in a bad state somehow. I also deleted the the .sou file, but I don't think that was the issue.
I received the same problem.
I fixed it by copying my webapp's DLL from the OBJ/DEBUG folder to the BIN folder.
I just had this error and found 2 ways to fix it, either:
Change the Codebehind attribute in the global.asax file to CodeFile and add "partial" to the class declaration
In the deployment project's property pages, set "Version output assemblies" and provide a version number
I don't really know why either worked, but it did.
solution :
-p Site path must have the directory path of .csproj file location.
ex :-
aspnet_compiler -p D:\Projects\MGM\mgm\mgm -v / D:\Projects\MGM-deploy\mgm_compiled