_NativeStripFiles fails when building release build to upload Apple Store

I do not know if this is relatively known. This xcode-select --switch command.

Anyway, this is what happened to me. As it took sometime for me to figure this out. It is probably worth taking note.

First of all, I had multiple instances of Xcode installed on my Mac.

To be more precise, I have got a new Mac recently, a few months back. By then, the latest Xcode was 15. Naturally, I installed it.

Then I found that Visual Studio (I develop a Xamarin app) of that moment does not work hand-in-hand with Xcode15. I installed Xcode 14.3, keeping 15. They are sitting in different folders. In Visual Studio, I specify 14.3 as Apple SDK.

All went well. I built and published my app with the 16.4 SDK which comes with Xcode 14.3.

Sometime after that, I felt the need of using 17 SDK (I wrongly believed that this is required to support iOS17 devices). I found that with the Visual Studio update out in Oct 2023, I can use Xcode15 SDK (which is 17.0). The new build runs OK on an iOS17 simulator. So far so good.

To release to App Store, we need to build the app against an actual device, as you know. Then I have got this error:

xcrun: error: sh -c '/Applications/Xcode_14.3.1.app/Contents/Developer/usr/bin/xcodebuild ...

What?! Why this still tries a command of Xcode14.3, even after I have switched the Apple SDK to use to Xcode15!

I looked everywhere, Googled for a hint. No chance.

Helpless, I told myself how happens if I removed the Xcode14.3 installation folder.

Bingo! Now the error has changed and saying:

xcode-select: note: No developer tools were found, requesting install.

If developer tools are located at a non-default location on disk, use `sudo xcode-select --switch path/to/Xcode.app` to specify the Xcode that you wish to use for command line developer tools

With this message, I have come to know that I need to run the command to tell the system the Xocde I want to use.

Debug a Release Build

Another post really for myself to keep a good pointer, and/or thing(s) learned.

I had a code in C++, which runs OK in Debug build, but not in Release build. Not running here I mean that it crashes, fails even in exception trapping. After all, I found out that it is due to a library implemented by a colleague, which exit when an exception happens in Release build, while passes the exception to the caller in Debug build.

Looking back, this could have been found, by stepping through the code in Debug build. Apparently I did not have such a patience, and found it only by “debugging the Release build”.

It turned out be pretty simple. Just by following the instruction found at https://docs.microsoft.com/en-us/cpp/build/reference/how-to-debug-a-release-build?view=vs-2017.

The step 6 says:
You can now debug your release build application. To find a problem, step through the code (or use Just-In-Time debugging) until you find where the failure occurs, and then determine the incorrect parameters or code.

At the beginning, it was not clear to me how??? But then realized that I just need to push the usual green arrow .

Building Log4cxx with VS2015

I do not think this interest many. Me myself may not come back to this again. I found it not work with my Qt app, at least as is, and so have gone to “a blend of” Log4Qt. But I spent an entire day for this, so want to leave the log somewhere...

Anyway, first of all, what is Log4cxx?

It is the C++ port of the famous Log4J. I have been using Log4Net (Not J ), so wondered if there is the same for my C++ app.

The official instruction for the build can be found here. But apparently many are having difficulties in doing it. Google “log4cxx visual studio” and you wiil see.

Let us start with downloading the required packages. # By the way, I have never succeeded in the signature checking... But no time for it now.

For apr and apr-util, newer exist. But the util package does not contain the xml VC project referenced by the main log4cxx solution. So I sticked to their versions of the instruction.

Building apr failed. This blog post How To Build Log4cxx In Visual Studio 2010 helped.

It reads: If apr fails, and you find out _WIN32_WINNT is less than _WIN32_WINNT_WINXP, ...

This was too cryptic to me at the beginning.

_WIN32_WINNT is defined as follows in the project.

#define _WIN32_WINNT 0x0400

_WIN32_WINNT_WINXP is said defined as 0x0501 in the Windows header files. ref. Using the Windows Headers

So I added the precprocessor definition as instructed.

Proceed to builing the main log4cxx project, and have tons of compile errors just as predicted by the blog post.

However, for VS2015, the solution appears not the one presented there, but the same for 2012 instead.

Thanks GOD. Now the number of compile error comes down to only one, which is removed by adding #include <iterator> in stringhelper.cpp.

Finally, there are a handful of linkage error to resolve. It says here that it has started with VS2013, Gorsh!. How to take out the function casts is detailed here.

Thanks GOD! I have got the DLL and confirmed that it works with a test win32 console app, but not my actual Qt app...

No real alternative yet for FrontPage Server Extension

After days of frustrating analysis, my conclusion at the moment is to stay with the now-has-become-a-third-party-product FPSE.

My requirements are:

1. I, the server administrator, do not want to do much. I do not want to be called to intervene each time a web site is to be created. Once I have appointed developer A for admin of web site host/siteA, I do not want to have to intervene for host/siteA/siteA1 etc. Moreover, when he has got a colleague who assumes the same role as him, he could do the necessaries.
2. Operations for developers such as managing the web site permission, deploy their codes, should be straightforward.

With FPSE on a 2003 box, it has been near perfect. Except for one thing. No means that developers can verify if a folder is setup as “application”. They can turn a folder into an application, but cannot verify.

The story started when we start thinking of upgrading our web server, currently IIS6 on 2003 box, to IIS7.5 on 2008 R2. Soon I came to know that FPSE is no more supported. There is one as a third party product, but not from MS. Not yet for IIS7.5 but it is said to become available soon.

What is then the MS’s alternative? None that I can see.

Visual Studio 2010 supports the followings for code deployment.

1. FPSE
2. FTP
3. Network share
4. Web Deploy # Only for Web Application Projects
5. WebDAV # Some say you could, by mapping it as (or like) a network drive.

I do not know if you agree. But to me, 2 and 3 seem going back to the stone age.

4. Web Deploy should be the first choice. It is new so must be better. But some say that converting a web site project to web application is not as straightforward as you may think. In addition, it does not fulfill one of my requirements above. The server administrator has to do whole a lot!!

If I setup the “Application” host/siteA for developer A, he could autonomously do the child application host/siteA/siteA1, by importing the siteA1 application with the IIS7 Remote Administration. (I so far fail to do the same with VS though) But he cannot give the permission to his colleagues by himself. It is understandable. When the server administrator setup an application, he needs to not only configure IIS Manager Permission but folder permission as well, while with FPSE you do all these in one go.

Finally, 5. WebDAV too appears to have the same shortcoming, lacks the permission management delegation capability that we want. It is said “The IIS7.* WebDAV extension module supports per-URL authoring rules, allowing administrators to specify custom WebDAV security settings on a per-URL basis.” But as it reads, it is for (server) administrators only. When you connect to a site or an application, with the IIS7 Remote Administration, you do not have the WebDAV Authoring Rules icon. And to connect to the server (then you have the icon), you need to be the administrator...

And above all, needing to map WebDAV folders for publishing web sites from VS does not sound to me an optimum solution...