add more readme details for the native part

ZitiNativeApiForDotnetCore/README.md

@@ -35,15 +35,13 @@ and you're trying to update the native NuGet package, or you're just wondering h
 
 After installing cmake, gcc/msvc, vcpkg and any other dependencies that are needed, you'll first need to build this
 project. Since it uses cmake, and assuming your shell is located in the same directory as this readme, you 
-should be able to simply issue something like:
+should be able to simply issue something like what is shown below. The output will go to `./build` and it seems vcpkg
+is sensitive to trying to change the `binaryDir`. You'll also only be able to build one arch at a time.
 
 ```
-SET TARGETDIR=%CD%\build
-
-cmake -E make_directory %TARGETDIR%
-cmake --preset ci-windows-x64 -S . -B %TARGETDIR%
-cmake --build %TARGETDIR% --config Debug
-cmake --build %TARGETDIR% --config Release
+cmake --preset win64 -S .
+cmake --build build --config Debug
+cmake --build build --config Release
 ```
 
 When the build completes (shown here using the Windows x64 preset) you'll have two libraries compiled at:
@@ -52,13 +50,17 @@ When the build completes (shown here using the Windows x64 preset) you'll have t
 %TARGETDIR%/library/Release/ziti4dotnet.dll
 ```
 
-Inspect the [native-nuget-publish.yml](../.github/actions/native-nuget-publish.yml) action to see the exact set of steps performed, but really you will 
-probably (hopefully) never need to learn how to build this project.  
+(Every arch is different. Linux produces "libziti4dotnet.so", macOS produces "libziti4dotnet.dylib".)
+
+Inspect the [native-nuget-publish.yml](../.github/actions/native-nuget-publish.yml) action to see the exact set of steps
+performed, but really you will probably (hopefully) never need to learn how to build this project.
 
 ### C SDK Version
 The version of the C SDK is controlled in two ways. The first way is by setting an environment variable 
 named ZITI_SDK_C_BRANCH. The cmake file will look for this env var and use it, if it's supplied. The second
-is via the cmake file itself which often gets updated, but might not be _the latest_. 
+is via the cmake file itself which often gets updated, but might not be _the latest_. It's a good idea to update the
+CMakeLists.txt file with the latest C SDK every now and then. CI will use the environment variable, passed in when
+the action is invoked (manually).
 
 ## Upgrading the C SDK library
 
@@ -71,25 +73,15 @@ NOTE!
 > When upgrading the C SDK Library, you really should verify ziti.def and ZitiStatus.cs are correct.
 
 ### ziti.def
-If you explore the CMakeLists.txt file you will see there is a ziti.def file. This file is **REQUIRED** for 
+If you explore the CMakeLists.txt file you will see there is a ziti.def file referenced. This file is **REQUIRED** for 
 Windows library builds. It is also imperative that it is kept up to date. A 
-[.bat file named defgen.bat](./defgen.bat) exists in this folder which _should_ create this def file properly.
-
-To use [defgen.bat](./defgen.bat) first make sure you have run the build and have properly compiled the project.
-
-Assuming you have done that, you then need to run defgen (requires dumpbin), which will output a ziti.def file.
-This file allows the exported functions from ziti.dll to be re-exported in ziti4dotnet.
-
-Example:
-```
-cd ZitiNativeApiForDotnetCore
-msvc-build.bat
-defgen 64 %BUILDFOLDER%\x64\_deps\ziti-sdk-c-build\library\Release\ziti.dll
-```
+[.bat file named defgen.bat](./defgen.bat) exists in this folder which _should_ create this def file properly. As of
+October 2023, the process was automated during cmake configuration using `FetchContent_Declare` and `URL`. See the
+CMakeLists.txt file for how it's done, it invokes `defgen.bat`. Make sure you commit the file.
 
-After you run defgen, there will be three extraneous files: ziti-exports.txt, ziti.dll, ziti.exp left behind.
-defgen leaves these files behind in case you need to do deubgging on the process but these files should not
-be checked in (they are .gitignore'ed).
+After you run defgen (or it runs automatically), there will be three extraneous files: ziti-exports.txt, ziti.dll, 
+ziti.exp left behind. defgen leaves these files behind in case you need to do deubgging on the process but these files
+should not be checked in (they are .gitignore'ed).
 
 #### Seeing What Changed
 You can see the delta between what was checked in and what defgen generated with this manual process/flow:
@@ -116,59 +108,5 @@ If you are getting errors indicating a function is not found, it's likely due to
 it's not included in the cmake file. Follow the steps above.
 
 ### ZitiStatus.cs
-The C SDK has a macro that generates error codes. These codes are not quite as nice to use as a C# enum so this 
-project is also responsible for generating a small amount of C# which represents those status/error codes. When
-the C SDK changes, remember to recreate and commit the ZitiStatus.cs file.
-
-Here's how you can regenerate the file manually. You can either clone/fetch the version of the C SDK you are 
-targetting - or just generate this project's meta data (which I think is easier).
-```text
-SET TARGETDIR=_TEMP_
-cmake -E make_directory %TARGETDIR%
-cmake -S . -B %TARGETDIR% 
-cl /C /EP /I %TARGETDIR%/_deps/ziti-sdk-c-src/includes /c library/sharp-errors.c > ../OpenZiti.NET/src/OpenZiti/ZitiStatus.cs
-- OR if using gcc not developer command prompt -
-gcc -nostdinc -E -CC -P -I%TARGETDIR%/_deps/ziti-sdk-c-src/includes library/sharp-errors.c > ../OpenZiti.NET/src/OpenZiti/ZitiStatus.cs
-```
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-## For Project Contributors
-
-If you're cloning this package with the intention to make a fix or to update the C SDK used, here's a
-quick punchlist of things you will want to review and understand before really digging in. This will
-take you through just the bullet points of what you need to do to make sure you can develop/test/debug.
-
-Things you should do/understand:
-
-* Build the native project for x64
-* **If** you're using Windows, also build the native project for x86 (win32)
-* Package the native dlls into a native nuget package. This boils down to putting the dll for YOUR operating
-  system into the proper location, edit [the nuspec](./native-package.nuspec) and hack out the lines
-  you don't want (or better copy that nuspec to a different one you don't end up committing). then package
-  it, and publish it to a **local** NuGet repo path and use it locally. A convinience script exists at the
-  checkout root named: `dev-build-native.bat`. It is designed for Windows/Visual Studio development.
-* With the Native NuGet package built
+As of October 2023, the `ZitiStatus.cs` file is generated by a powershell script invoked from cmake if the cmake
+param `GENERATE_ZITI_STATUS` is set to 'yes'. See [generateDotnetStatus.ps1]() for how this is accomplished.