Motivation — I had a new version of my Cocoa application ready that worked fine on all beta testers' machines. So I released it. Turns out that a crucial feature simply doesn't work on anybody else's computer. Yikes! Yes, read that again: I released software that didn't work.
Cause — Users who had used previous versions my app (read: all my loyal beta testers) already had a folder ~/Application Support/MyApp/ from an older version. Due to the critical bug in the new release, this folder was necessary for the software to work. And for everybody else, because the folder did not exist, it didn't work.
As you can imagine, this is extremely embarrassing, and I want this to never, ever, happen again.
Remedies? — The straight-forward way to ensure this, of course, is to actually download and install it on a "clean" machine just before you publish a new release. But this seems impractical, because in time I will run out of friends with a Mac who have never tried my app yet (eventually all will have ;-)), and because I'm not eager to "format c:" my Mac before every single release…
This is where I need your help:
How can I ensure that a user who has never used my software before will get the same results as someone who has?
Virtual machines (VMWare Workstation, etc.) can be useful for testing clean installs of applications. You can start up a new virtual OS, install your stuff, test it, then delete the VM when you're done. There are ways to automate the spinning-up of a VM as well, which can make your life even easier.
Another thing to do is to determine all the prerequisites your app requires, and add checks for these things at startup. If something is not setup right, you can either attempt to set it up within your code, or inform the user to do it.
A more lightweight approach might be using tools like AppZapper to get rid of everything — temporary files, preferences, cache, history, etc – related to the app to test.
Related
My visual studio code seems fine and all of the sudden boom its crashed. Searched google for the error code No solution found. Any help would be appreciated.
error code = -536870904
Whenever anything stops working for no apparent reason then think:
Did it work before?
No, it is new or it has not worked yet.
Check your download, ensure it is compatible with your operating system and other running programs.
Yes, it used to work, but now it doesn't.
Look at the next step
Did you recently update the program, your operating system or any other programs?
Yes, I updated something.
Try rolling back your updates to see if it works again. New versions of software tend to be more error prone than the older, established versions.
No, I don't think I changed anything.
Either you are unaware of changes made to your system or some subscription has ran out. At this phase, the best option is to use common sense or uninstall and reinstall.
Another issue that you might be having is if you're running too many programs at once and your computer is force closing programs to protect itself. Try monitoring your Task Manager you may see a spike right before the crash. Also, make sure the crash isn't caused because of trying to run code (especially with code that has infinite loops)
I'm a software developer who works as a freelancer, and my question has two parts.
First part:
I was working on a project then out of nowhere while testing on windows 10 VM windows security start blocking my app, I have a legit Bitdeferter and Malwarebytes on my main machine, and when I scanned my app (the EXE file from C# project) everything is clean, yet when I uploaded the file to virustotal.com it shows 5 detections
I start doubting my code and NuGet packages (I use Microsoft.AspNet.WebApi.Client and Newtonsoft.Json) so I removed them and to my surprise, I only got 2 detections out of 5.
I even create an empty Console app and still get those 2 detections, and my main machine still shows nothing as a virus.
So does that mean that my app is good but needs to be signed?
Second part:
If my issue is just a signing certificate, do I need as a developer to obtain that or my client, and then I only sign his/her app under his/her certificate?
Thank you.
Many engines treat VirusTotal samples very harshly, and any new executable has very low reputation (never having been seen before).
Therefore you will get lots of false-positives from VirusTotal when looking at your own new binary.
Signing is likely to help somewhat - at least there's a chance that you can build reputation in your certificate rather than each binary separately.
As far as I know, you get the signing certificate for you as a developer, although that might be different if you are providing source code and the client is building the end executable.
When I wanted to export the model I was working on as a Java application, I encountered an error regarding the databases I loaded into the model. When I said OK to the error, I realized that all the files in the folder I wanted to create the Java application were deleted. That folder was desktop by the way.
Right now all the files (i mean all of them!) on my desktop are deleted and they don't even show up in the recycle bin. How are we going to solve this situation? How can AnyLogic have the authority to delete all files in that folder? How is this authority not shared with me and not warned beforehand?
When you work with software in general, you need to have a version control in place that will allow you to recover your information. These problems occur, and if AnyLogic has access to your computer it's because you grant the permission and it needs the permission. If you make your desktop your project folder, then i would say you are to blame.. why would you do that...
Using GIT as Ben commented, is always a good idea... but it requires you to be conscious about when you commit a version.
What I do, is I use dropbox and all my projects are done in a dropbox folder... the good thing is that dropbox always saves automatically all the files on the folder... this has saved my life multiple times and I suggest you to do something like that in the future. So on one hand you have the autosaving features, which is useful, but sometimes you erase everything by mistake, and the autosave is not useful, but dropbox saves no matter what.
I have a simple GWT app.
Whenever I run gwt compilation for production, I also see a file with the extension .devmode.js being generated.
Questions:
This looks like a devmode-related file; do I actually need it while running in production? Do I need to delete it?
What does it do?
If useless, is there any way to stop it from being generated while in production?
I'm using GWT 2.8.
Kind regards,
Andrei
It is specific to legacy Dev Mode, and not used in Super Dev Mode. If you don't ever use legacy Dev Mode, you don't need it.
You don't need it in production... unless you ever need to debug your app in production. If you ever want to debug your app in production (with legacy dev mode), you should leave it.
You do not need to delete it - it will not be used unless you attempt to enter dev mode, and it is a static file, and cannot be used to maliciously debug your app, unless the attacker also has all of your original Java source code already.
The Linker system does not currently have a way to prevent it from being emitted. The "generation" of it is very simple, only the __MODULE_NAME__ tokens are replaced with the name of your app, so there is essentially no penalty paid in creating it.
Unless you need the extra 1k of disk space in your generated app, I wouldn't worry about it at all as there is no risk in having it. If you do need that extra 1k, either modify your current linker to avoid emitting it, or add a later build step to delete it.
Ok
SO recently I've being having a lot of trouble with an application working in debug mode but not working in distribution mode.
Is it possible to use xcode debugging tools such as break points and variable tracing with an adhoc distribution build of an app?
If it's not how would one usually go about debugging such a thing?
Assuming that your crash logs aren't giving you any clues (you'll need to hook up to the device to get them) there are lots of things you can do.
But I'd start by looking at the crash logs ... the clues will be there and don't forget Apple make distribution crash logs available to you through iTunesConnect.
1) Copious logging is one thing. Lots of developers use a switch so that in debug, logs go to the console but for other builds they are dropped. Consider a different option where you log to a file instead. You could then push the log files to a remote server for debugging. It's a bit of a slog to set this all up, but once you've done it, you'll wonder how you ever lived without it.
2) Another option is to use Flurry and log events when you detect that things have gone wrong. This can cover more controlled problems when things aren't as expected rather than random crashes. This can be a useful feature for released apps provided your terms and conditions are clear about what data you are logging and why.
3) Make sure you do a clean build, I'm sure you've already done this, but sometimes it clears these issues.
4) Are you using external libraries / modules? I've come across issues with older versions of TT where the arm6/7 build settings were wrong and this was causing issues for distribution builds. Basically check through the build settings for each profile and make sure it is what you expect.
5) Suspect a race condition. In distribution mode (often because the logging is turned off) you will find that your application runs a little bit faster. That can reveal timing issue bugs in badly written code.
So yes ... there is a lot you can do ... you just can't attach the debugger ;-)
Not possible to debug an application in distribution mode.
The build configuration difference between Distribution, Debug, and Release is really whatever parameters you have set for that in XCode. If your Distribution config is giving you problems and the release isn't, the easiest way to fix it is to go back through Apple's steps on copying the Release config and making the changes to make it a Distribution config, like you did originally.
The alternative is to go through every line of the configurations for Release and Distribution and find what's different. The other way is a LOT faster. :)