I created a lightaddon. When I tried register the ard file of addon, I got error, add-on installation failed because another version is already installed. I followed the steps that are shown in below:
I checked SARI table in SBO Common but it wasn't record for the add-on,
I checked files AddOnsInstall.sbo and AddOnsLocalRegistration.sbo in C:\Program Files\SAP\SAP Business One but again there is nothing about the add-on,
Finally I deleted directory of add-on from C:\Program Files\SAP\SAP Business One\AddOns,
But still I cannot solve the problem, could you give me a solution?
Regards
You must check the table OARI. If it has rows, then DELETE OARI.
Have you made sure that the AddOns folder in SAP Business One has read/write full rights?
Also did you package your addon as an x86 compatible?
Related
I've tried for many hours to find the solution for my problem and couln't find it even here.
So I have that application.exe that I am writing the Wix Toolset installer for it. Unfortunately I have no access to the source code but I hope I can do my task without it.
The problem is that it runs correctly with vc_redist.x64 installed on the end user's machine, but not without it.
What I've tried:
I was trying to run it without those runtimes and got into "couldn't find vcruntime140.dll error"
So I pasted it in the app's folder and tried to move on with dll's and the next error occured as shown in picture:
the application was unable to start correctly (0xc000007b). Click OK to close the application
I've read those runtimes after installation go into eg. "C://Windows/System32"
so I tried to go to that location and
dir > before.txt
and
dir > after.txt
after installing the vc++ runtime.
and copy pasted the files that occured only after the installation.
I tried to use gumpbin.exe from Visual Studio that gave given output:
found some dependencies
and the Dependency Walker gave me kind of similar output.
Dependency Walker output the same libs as direct ones, but also gave imo about hundreds of indirect ones. So I thought copy/pasting all of them is a really hard job without software to help.
I was also thinking about forcing vc_redist.x64.exe to extract files to folder given by me so I could use them for my purpose and the only parameter that looked fine was /layout but it only copied the whole .exe to another folder. Didn't extract it.
My questions is:
is there an easy way of obtaining the vc_redist.x64 libraries so I could author only the needed ones in my installer?
Any help will be appreciated. Thanks in advance!
Edit:
My goal is to secure newbie end users from being unable to run the application when they accidentally uninstall the VC runtime, therefore having vc_redist.exe as prerequisite in bootstrapper is unfortunetely not the case
We have 2 installer sources in WiX to create installer for a single product with same Product Version, GUID and Package GUID also.
Those 2 installer projects will yield different outputs, one output being just a single MSI file (File1.msi) and other project output is a CD-ROM structure having different MSI file name (File2.msi).
So now issue arises when we installed the product using single MSI file, upon that if we invoke MSI from the other CD-ROM output, we end up getting below mentioned error.
I tried keeping same MSI filename for both kind of installer output, then this above error dialog was resolved but repair functionality isn't working.
If some files were deleted in the product's destination folder, it says source file not found error pointing to CD-ROM installer source folder.
Please help where I'm going wrong. I want to support Repair installation without this errors.
The dialog is expected. You can't change the name of the MSI except during major upgrades.
After that, if you rebuilt to create the different layouts, each MSI probably has a unique PackageCode and that makes them unique packages. That is most likely why repair isn't working. A verbose log file should tell all.
Updated: Compile your main MSI, then run administrative image on it and put the extracted files and MSI on the CD? Put the compressed
version on there as well - just in case they prefer that kind of
release (happens).
I am not sure what will happen when you run both setups this way, but
I think the MSI flagged as an administrative image extract might be
detected by the engine. I am not sure. Should work. Built-in approach for MSI, and you are not fighting wind-mills.
User Accounts: Are you creating any NT User Accounts? Did you set the FailIfExists attribute to yes? Please check here:
User Element (Util Extension). What is the setting for UpdateIfExists? (if any).
Other Issues: There might be other issues as well as Rob mentions. You can not use the same package code for both release types because a package code by definition identifies a unique file. All kinds of X-Files-like problems occur if you try to "hack" this. Not a fight you want to take on.
Administrative Installation: Why would you want to distribute different setups on CDs these days? Corporations that use your setup will run an administrative installation on your setup extracting all files - which is a much better concept. It is essentially a glorified file-extraction, and it is a built in Windows Installer concept intended to make a network installation point for software - among other things. It essentially extracts all files and translates the Media table to use external source files.
List of Links:
What is the purpose of administrative installation initiated using msiexec /a?
Extract MSI from EXE
OK - here we go again. I posted an almost identical question here, but this one is a little different. I just generated a new version of a NuGet package and updated all of our csproj and config files to point to it and it builds locally fine, but when I kick off a TFS build it fails with the message:
##[error]ASPNETCOMPILER(0,0): Error ASPCONFIG: Could not load file or assembly 'PacsgearLib, Version=2.5.4.0, Culture=neutral,
PublicKeyToken=05b30ac9ab9dbb8e' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)
Pacsgearlib 2.5.4 is the NuGet package I just generated, but all of our other projects build fine (and they share a lot of the same code). The main difference is that this project has a website in it. MSBuild is version 15.5.180.51428.
Here's a picture of the actual error:
Any ideas here? I've tried NuGet package manager to uninstall the package and reinstall it for the website and that hasn't helped.
I've been at this for a few hours so I thought maybe someone else (or a second set of eyes) might help.
I also just saw this and will check it out first thing Monday morning.
I finally got this to work by taking out the assemblybinding section of the web.config (someone else suggested that in another related post) and I also found a few .csproj files that had not been properly updated and were still pointing at 2.5.3.
If the local builds fine, and the error exist with TFS build. Besides, all of our other projects build fine (and they share a lot of the same code).
Combine with both, the issue may related to the specific package PacsgearLib, Version=2.5.4.0 on build agent. You could try to delete the packages and clean build agent, then try again.
Another way is update your package version number(do not update the package content), use TFS trigger the build again. Check if TFS build server will pick up the latest version of package.
Also set system.debug=true to Enable Verbose Debug Mode with more detail log info for troubleshooting
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.
I am trying to publish my application using installShield utility. Every thing works fine but it gives warning that it asks for two files:
libc.dll
Flash32_11_7_700_224.ocx
Those two files are prerequisite according to the package but I could not find them.
I tried to search in the web for those two files with no luck.
Can any one help in this?
Explanation of Error
This error can be encountered in Flexera's InstallShield. The specific error is:
ISEXP : warning -6248: Could not find dependent file <dependent file>,
or one of its dependencies of component <component>
The official troubleshooting information from helpnet.installshield.com did not help me, but it says to:
Use the "Build Tables & Refresh Files" option to build the release
if the release location is in <ISProjectDataFolder>
or <ISProjectFolder>. For more information, see "How the Run time
Locates Assemblies", available in the .NET Framework SDK help or on MSDN.
Workaround
If the application works fine, and you just want to get rid of the warnings, you can follow this Stack Overflow Q&A.
(InstallShield, Installation Designer, Left Panel) Specify Application Data > Files
(Destination computer's files panel) Right click primary output > Dependencies from scan at build... > Uncheck dependencies you do not want
The above picture from the Stack Overflow answerer #Tom Wilson shows what you should see. Note that primary output was the central .exe of my project. When I used this technique on my primary output, the other components in my project were also fixed.
Resolution
If this problem is crashing your application, and not just an annoying warning...
In the case of libc.dll, I would direct you to add Redistributables to your project.
(InstallShield, Installation Designer, Left Panel) Specify Application Data > Redistributables
For instance, I use Microsoft .NET Framework 4.7.1 Full.
I believe this solution will work for libc.dll, but cannot verify. I base this on reading support.microsoft.com, which I think implies libc.dll is contained in C Run-Time (CRT), which I would also believe is part of the .NET Framework.
In the case of flash32_11_7_700_224.ocx, I would direct you to System Software Requirements. This ocx is installed with many Adobe products. You may want to prompt the user that they need to install this, at the time software installation.
(InstallShield, Installation Designer, Left Panel) Define Setup Requirements and Actions > Requirements
(Central Panel) System Software Requirements > Right click > Create New Launch Condition (System Search Wizard)
Follow the wizard there to block installment if it does not exist, or use one of the premade requirements if that helps your case. Tip: remember to supply a link to Adobe in your prompt, so your end-user can quickly download it!