Why tsNet.bundle?

[stephenmcnutt]

I guess I have three related questions, found at the end of the following three paragraphs...

When my standalone is built, tsNet.bundle gets included in one of the Externals folders. This tsNet thing is for Internet functionality, right? My app in no way accesses the Internet. I don't know what might be fooling the standalone builder into thinking tsNet should be included. Any ideas?

If I try to delete tsNet.bundle from the Externals folder, my standalone will no longer launch. I don't know, but I think this is because some plist or something is telling it to look for tsNet.bundle. What else do I have to edit to get rid of tsNet--if that's something I should be doing?

The problem tsNet is causing (or I'd maybe leave it in) is that when attempting to use Xcode's Application Loader to deliver the app to the Mac App Store, I'm getting a warning (a CFBundleIdentifier Collision) that the CFBundleIdentifier is already used by au.com.techstrategies.external.tsNet, which I assume is the company that makes tsNet. What do I do about this Application Loader error?

[quailcreek]

What version of LC and xCode?
Do you have the tsNet library checked in the inclusions?

[stephenmcnutt]

LC 9.0.1, latest Xcode (just downloaded it today)

I'm letting it figure out the inclusions, but I guess I should select them manually.

[jacque]

If you are building for mobile, look at your standalone settings and see if you have Internet permissions selected. Standalone settings partly determine what inclusions are used. On iOS it's called "WiFi" and on Android the permission is "Internet".

If your scripts use URLs, even just to access local files, the standalone builder might be assuming you need internet access for desktop apps too.

[stephenmcnutt]

Yes, my code does use URLs for copying some local files. Example...

put URL ("binfile:" & gMacPackageFilePath_Settings_Saver) into URL ("binfile:" & gMacLibraryFilePath_Settings_Saver)

The only reason I resorted to this URL business is because whatever "normal" command, probably "copy" wasn't working. It's been years since I had to work through that, and I don't recall the details exactly. I think it had something to do with these "copy" (put URL) commands coming very early after the app launches, and "copy" wasn't working because it somehow wasn't available yet. So I solved it with this "put URL" thing.

But my using "put URL" probably explains why the standalone builder thinks I need that tsNet Internet inclusion. I'm not sure what to do at this point. If I specify inclusions manually, the standalone's "answer" dialogs don't function. I have only the three automatically selected inclusions checked: answer dialog, ask dialog, and, I think, cursors. If there's something else I should check, I have no idea what it might be, which is why I've been using automatic inclusion selection.

At this point, this post has pretty much merged with my other post in this forum, "Answer Dialogs not Working in Standalones".

[jacque]

I suspect you were using revCopyFile, which is in a library that doesn't load until after openBackground finishes. Moving that command to a preOpenCard or openCard handler should allow it to work.

I have never experienced a case where the answer dialog didn't function. It's always included in a build and it's always been available. It also doesn't make any sense that auto-inclusions work and manual inclusions don't (I always use manual inclusions.) So I'm pretty well stumped on that, and can only suggest that you ask the LC team to look at it.

I explained a little bit about remote debugging in your other thread. When it works, it's immensely helpful.

[stephenmcnutt]

I can't seem to make it stop including tsNet.bundle. I've replaced the put URL commands with revCopyFile commands and searched my script to make sure all instances of the word URL are gone. Yet the standalone builder keeps including tsNet.bundle.

There are really two problems. I'd like to solve both, but solving either would work, I think. Problem #1 is as described in the paragraph above: I can't seem to shake tsNet.bundle.

Problem #2 is something I mentioned in my initial post in this thread. I'll paste it here for easy reference...

The problem tsNet is causing (or I'd maybe leave it in) is that when attempting to use Xcode's Application Loader to deliver the app to the Mac App Store, I'm getting a warning (a CFBundleIdentifier Collision) that the CFBundleIdentifier is already used by au.com.techstrategies.external.tsNet, which I assume is the company that makes tsNet. What do I do about this Application Loader error?
(end of pasted bit)

Why is having tsNet.bundle in my standalone causing this collision error? It's like Application Loader thinks I'm trying to take credit for tsNet or that tsNet is the main bundle or the main CFBundleIdentifier instead of my app.

[charlesBUSd8qF]

Hi Stephen

Trevor DeVore noticed this as well and posted the following on the mailing list:

You need to replace “au.com.techstrategies.external.tsNet” with “com.YOURCOMPANY.YOURPRODUCT.tsNet” in the Info.plist file in the tsNet.bundle.

Charles.

[stephenmcnutt]

Thank you very much, Charles. That did the trick. No more BundleIdentifier collision when uploading app to Mac App store with Xcode's Application Loader.

Now, has anyone reported this as a bug or whatever needs to be done to ensure it's fixed?