electron-builder failing to generate .nupkg - electron-builder

I went to do a fresh update server deployment of an application (via -full.nupkg) the other day and was surprised to see that the file does not exist in my dist folder. I've run through and rebuilt on Windows, but I'm only getting the .exe and unpacked folder versions.
I can't recall when I last did a full build with .nupkg deployment, it may have been a few months. I've tried rolling back any changes that I could think of that are related (other than electron-builder itself, which I can't roll back any further as it has a critical bug fix in it for us for one of our platforms).
My next thought was a bug in electron-builder or that they removed that feature. However, I don't see any current bugs about it, and the documentation I've run across (while being a bit vague) at least seems to suggest that it's still available.
I did see some references to an "electron-builder-squirrel-windows" module as a recommendation too, but I can't actually find that module. Is that what I need/what broke? If so, where can I find it?

Please set target to squirrel. To use Squirrel.Windows please install electron-builder-squirrel-windows dependency.

Related

Archiving automatically says it is complete even though it did not create an archive (Maui in VS22)

Trying to create an archive to make a release apk of my app, and whenever I click archive all, it instantly says the archive is completed, nothing shows in the archive manager, and there are no errors or absolutely anything for that matter shown for output.
I suspect it may have something to do with the versions as I was able to archive previously, but once I changed versions, I believe that is when the issue started. Also, the app builds and runs with no issue.
I think the tooling for publishing and archiving is still work in progress. I'm not 100% up to date with the status though. However, if you run into these things please report it through the Visual Studio Help menu and choose Provide Feedback > Report a Problem.
That will make sure it goes to the right team with all the right information attached.
As a solution for you right now, the command-line does work. Everything needed to create a version is described in the docs: https://learn.microsoft.com/dotnet/maui/android/deployment/overview
I have come across the same issue I think I may have identified the what may be causing the problem:
I did the following:
Created a new .NET MAUI App with .NET 7.0 (Standard Term Support). Without
changing anything - I selected Archive All - this worked fine.
Changed the following project property:
Changed from:

How to prohibit the .pkg installer from searching included .app (s) in locations different from the specified installation dir,

This issue has been discussed several times on Stackoverfl0w, but unfortunately I did not see any really satisfying solution.
The situation:
(Only included because most previous answers went with the line of "Just dont do it! There is no reason to have multiple version of an application.. etc.", which I agree with for most cases, but not this one.)
We are currently shipping a .pkg file that installs our software package to /Applications/$CompanyName/$SoftwareName_$VersionNumber .
Including the Version number in the folder's name and not deleting older versions is necessary since many of our customers use our current release and beta version in parallel, and, furthermore, many customers work with an older version software because they certified it for a specific use case, but they use a current version for current projects.
We used to ship only command line tools and libraries for macOS, therefore it worked totally fine for us over many years.
However, we started porting our GUI applications from Windows only to Windows / macOS / Linux, which are shipped in the .app format under macOS.
The issue:
If an .app is shipped within a .pkg installer, the installer searches the hole disk for old instances of the same .app .
If it finds one, it replaces the instance it found (very bad) and also does not place the .app in the specified installation dir (also bad).
Solutions I found:
a) Changing the CFBundleIdentifier of the .app for every released version. Seems not like a clean way to me. I assume it will also cause the .app to appear multiple times in the Launchpad
b) Searching all instances of the .app before the installer does it, zipping them, and extracting them again after the installation. (Also does not sound like a good solution.)
Does someone have a clean way for this?
Can not believe that Apple does not have a way of specifying that this behavior should be omitted during the creating of the .pkg.
Is there better documentation then the one I found?:
https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/DistributionDefinitionRef/Chapters/Distribution_XML_Ref.html#//apple_ref/doc/uid/TP40005370-CH100-SW15
http://s.sudre.free.fr/Stuff/Ivanhoe/FLAT.html (Good documentation, but after ~8 years of uptime, a lot of the fields are still labeled with "Description Forthcoming.")
EDIT:
Added XCode as a Tag.
Bumping after earning the tumbleweed with this question.
Would appreciate any suggestion :)
The "relocate" property in the distribution file seems to control this. Unfortunately, it appears you can only enable "relocation" by adding this key, but not disable it by omitting the key. According to Apple's Distribution XML documentation, the default for .app bundles is "relocate".

.ini file not being modified/updated when doing an upgrade with installshield since some folders are not being deleted when upgrading

Not too long ago I got a new job working on a tool that the company created to make people's lives easier when working on AWR.
I have successfully done multiple fixes and improvements which I was able to distribute via HotFix installers (simply overwrite the files that are already there).
My latest change/addition to the tool requires I create a complete installer for the tool. This particular tool always installs 2 versions, the current/new and the previous/old, to give a smoother transition to users. I have never done an installer before so I am learning as I go.
I was able to create an installer using the previous installshield project by simply updating/adding/removing files and folders. This works great when there is no version of the tool installed on the computer and there are no files/folders of any version of it on the installation locations.
I looked online and found that to make an installer that will install over a previous version I would need to do a major upgrade with installshield, which I did do after reading that. Now the installer successfully installs over the old version, it successfully places the new files and folders on their locations but always leaves one particular empty folder behind, the one for the 1.1.1 version.
That didn't seem like a problem until I realized that the .exe failed to modify the .ini file that it needs to modify to let AWR know where to look for the scripts. I looked through the .exe code and after running some tests, running it alone, I realized the .exe is not the problem, it does the job correctly. After doing many tests I found that as long as those empty folders exist the .ini files cannot be modified. I have no clue why since the .ini file is pretty much a .txt file and it makes no sense for there to be some sort of dependency on the 1.1.1 folder.
So my problem is one of two, either I have to figure out a way to make sure that the upgrade deletes those 1.1.1 folders or find a way to modify the .ini files with those folders still there. I have looked online and every solution requires me/the user to manually do something and I am being asked to make the installer simply work when used. They are asking me to make it so the installer takes care of everything and the user should not do anything except run the installer.
Since the installer works correctly as long as those folders are not there I figured making sure the installer removes them is the best way but I am stuck and I do not know how to proceed.
Thank you for any advice and help you can provide with this issue.
Solution:
Deleted all files I needed to make sure were updated from the components list and re-added them to the installshield project.
Since doing that everything was updated correctly and the folders were removed since the .exe was the correct one.

Android Studio cannot re-import module

I'm posting this in hopes to help several folks who may be struggling the same way I am. I was just trying to fix my run configuration for a basic Android project in Android Studio when things went haywire. Ever since 2 updates ago my run config stopped working. It was somehow pointing to an apk path that had been changed. Something in the latest AS updates changes where the apk is built to without updating existing run configs. Long story lengthenedā€¦
I tried creating a new run config then tried running the old config. I got an error saying that I probably needed to sync my project with my Gradle build file. I clicked the "Refresh all GRadle Projects" sync-looking button in the Gradle tasks window when everything went awry. My module completely disappeared from the project! I tried re-importing from project settings then I started to get an error:
Could not install Gradle distribution from 'http://services.gradle.org/distributions/gradle-1.8-bin.zip
I couldn't figure this out because I didn't have this problem earlier and also I noticed my module file had been completely deleted! I tried a few more times before looking at the Android Studio logs which said something about it couldn't unzip the gradle 1.8 bundle or something. I realized it was trying to download something and that I was on paid wifi in an airport so the download couldn't complete. I then payed for wifi so that the download could complete and tried re-importing the project. I STILL got the error! After few more attempts I decided to check under ~/.gradle where I found and deleted "wrapper/dists/gradle-1.8-bin folder thinking the earlier download was corrupt and confusing AS. That seemed to get things going again as the next attempt triggered a download/install of something that allowed me to continue to the next step.
I'm currently still trying to re-import and set the module up again and it feels like a lot of re-work. I eventually got to a point where I was told my version of gradle was too old... (I have Gradle-1.7) I'm just throwing this out there now in case anyone else hits their head the way I just did. It can be an expensive mistake. (I'm still paying for Wifi so I can send this!)
I've finally figured out my issue. My build.gradle was set to use 'com.android.tools.build:gradle:0.5.+', which is incompatible with the latest version of Android Studio. After duplicating my project folder in Finder, updating to the latest Gradle, and tweaking the plugin version I am finally able to sync my project. I hope this post saves someone else a headache!

Visual Studio internal project references not always working

I am using Visual Studio and a solution with 10 or so projects in (mostly VB, some C#) which have various dependencies set up. Usually when I compile the solution it works fine. Occasionally when I do it I get a build error saying that one of the projects referenced is the wrong version (I think always the same one, possibly may be two that can cause problems). In this case going to the solution explorer and right clicking on the mentioned project and saying "rebuild" followed by another full build makes it work fine.
I assume there is something set up wrong somewhere but I didn't set up the solution myself initially and a quick look through doesn't show anything immediately wrong.
It feels like there is some kind of race condition, that VS is internally setting the version number of the project it needs before that project has been rebuilt and thus gets it wrong or something like that but I'm sure VS should handle all this sort of thing properly.
Can anybody please suggest places that I could check for whether this has been correctly set up...
And I should finally note that since I don't have reliable repro of this I may not be able to respond to questions too quickly. For example the obvious one of "Could you give the exact error message" will have to wait since I didn't think to copy it this morning, it was only after I cleared it up with the above steps that I thought to post here. Similarly any solutions may take a while to confirm.
Edit to add error message:
Indirect reference is being made to assembly ODP version 1.0.3792.16586, which contains '{{CLASSNAME}}'. This Project references a prior version of ODP version 1.0.3791.18659. To use '{{CLASSNAME}}', you must replace the reference to ODP with version 1.0.3792.16586 or higher.
Edit for more apparently relevant details
Since it has been bought up I will clarify that one of the projects is a web project and that it is this one which is generating the above error message.
Further edit
Having looked further there is a copy of ODP.dll in the bin diretory of my web project. Using windows explorer and right clicking, asking for properties and looking at the version it is version 1.0.3791.18659. Having deleted this (actually moved it elsewhere) when doing a build it recreated this file still with that same version number (ie an old version number).
ODP claims to be a project reference too which still makes me think it should just work... :(
Further Further edit
I think now that the problem is that if the ODP project changes then it gets rebuilt but it doesn't necessary cause all the projets that are dependant on it to be rebuilt. So one project might still be built against the old version and one against the new version. If they are then trying to talk between each otehr with objects from ODP then it goes wrong... I need to confirm this but I'm not sure what would need to be done to fix it at the moment. :)
Is the build order correct? I can imagine if you build one project which references the other one, and that one isn't built yet you can have this kind of problem.
Link: http://msdn.microsoft.com/en-us/library/5tdasz7h%28v=VS.80%29.aspx
If you have a website project, are you sure you have set these to be 'project' references rather than 'bin' references - you could be getting some issues this way.

Resources