JWrapper with JavaFX fails to launch on windows - jwrapper

We've got an application which we've recently added JavaFX to, and updated to the latest JRE, and now Jwrapper won't launch the application on Windows (MacOS and Linux are fine).
We've followed the instructions on this post http://www.jwrapper.com/blog/bundling-javafx-into-a-native-exe and changed our JWrapper config accordingly.
We are using JDK1.80_102 and JWrapper version: jwrapper-00044250826.jar. We are building via maven (we have a plugin that does this).
The application downloads, but will not launch. See the logs below:
+0 ----- Starting Launcher -----
+0 [Launcher] Arg[0]=C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete\bin\APPNAME (UAT).exe
+0 [Launcher] Arg[1]=-cp
+0 [Launcher] Arg[2]=C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-APPNAME (UAT)-00046316696-complete\jarname-all-3012-SNAPSHOT.jar;C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-APPNAME (UAT)-00046316696-complete\jwrapper_utils.jar
+0 [Launcher] Arg[3]=-Xms256m
+0 [Launcher] Arg[4]=-Xmx1024m
+0 [Launcher] Arg[5]=-Duser.groovyServer=groovy.server.url.com
+0 [Launcher] Arg[6]=-DcurrentEnvironment=UAT
+0 [Launcher] Arg[7]=-DreqServerVersion=2016-09-08:1.0-0
+0 [Launcher] Arg[8]=-DprojectVersion=3012-SNAPSHOT
+0 [Launcher] Arg[9]=-DstartBanner=o3gui/images/app_banner.gif
+0 [Launcher] Arg[10]=-Dswing.aatext=true
+0 [Launcher] Arg[11]=-Dapple.laf.useScreenMenuBar=true
+0 [Launcher] Arg[12]=-Dcom.apple.mrj.application.apple.menu.about.name=APPNAME
+0 [Launcher] Arg[13]=3
+0 [Launcher] Arg[14]=-Djavafx.macosx.embedded=true
+0 [Launcher] Arg[15]=jwrapper.JWrapper
+0 [Launcher] Arg[16]=C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-APPNAME (UAT)-00046316696-complete\JWLaunchProperties-1473288163056-24
+15 [Launcher] Found tail marker
+0 [Launcher] App Name = APPNAME (UAT)
+0 [Launcher] App Version =
+0 [Launcher] JRE Version =
+0 [Launcher] GU Version =
+0 [Launcher] Min Splash MS = 850
+0 [Launcher] Signature Public Key =
+0 [Launcher] Can Override Splash = 0
+0 [Launcher] Install Type = perm_user
+0 [Launcher] Silent Parameter =
+0 [Launcher] Update URL = 8
+0 [Launcher] ExePath is C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete\bin\APPNAME (UAT).exe
+0 [Launcher] Master dir from exe path is C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)
+0 [Launcher] Master folder is C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)
+0 [Launcher] Located existing bin JRE runtime = C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete
+0 [Launcher] JRE path is C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete
+0 [JNILaunch] Bin folder is C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete\bin
+0 File exists: C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete\bin\server\jvm.dll
+0 [JNILaunch] Trying to load library C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete\bin\server\jvm.dll [exists=1]
+1 [JNILaunch] Unable to load library. Will attempt fallback.
+0 [JNILaunch] Trying to load library C:\Users\username\AppData\Roaming\JWrapper-APPNAME (UAT)\JWrapper-Windows64JRE-00046316492-complete\bin\client\jvm.dll [exists=0]
+0 [JNILaunch] Unable to load second library.
+0 [JNILaunch] [ERROR] Unable to load JRE library!

NOTE: This is a workaround, not a fix for this issue.
If anyone else come across this problem, one workaround is to use the 32-bits Windows JRE.
As it can be noticed in the log, when JWrapper is starting the JNI launch, it will try the "server" JVM first (...\bin\server\jvm.dll), which is present in the 64-bits JRE.
And then, after it failed for some reason (JWrapper doesn't provide any useful information about it), JWrapper will try to load the "client" JVM (...\bin\client\jvm.dll).
The "client" JVM doesn't exist in the 64-bits JRE (and it's not there for ages, not sure why JWrapper is still trying to load it).
Now, if you use the 32-bits version, you should notice a change in the log:
++++++++++++++++++++++++++++++++++++++++++++++++
[JNILaunch] Bin folder is C:\Users\IEUser\AppData\Roaming\JWrapperApp\JWrapper-Windows64JRE-00046325420-complete\bin
[JNILaunch] Trying to load library C:\Users\IEUser\AppData\Roaming\JWrapperApp\JWrapper-Windows64JRE-00046325420-complete\bin\server\jvm.dll [exists=0]
[JNILaunch] Unable to load library. Will attempt fallback.
File exists: C:\Users\IEUser\AppData\Roaming\JWrapperApp\JWrapper-Windows64JRE-00046325420-complete\bin\client\jvm.dll
[JNILaunch] Trying to load library C:\Users\IEUser\AppData\Roaming\JWrapperApp\JWrapper-Windows64JRE-00046325420-complete\bin\client\jvm.dll [exists=1]
[JNILaunch] Unable to load second library.
[JNILaunch] [ERROR] Unable to load JRE library!
[Extractor] Return code for JNI launch was 1
------------------------------------------------
--- End: JNI Launch
------------------------------------------------
[Extractor] JNI launch failed. Attempting legacy spawn instead
[Extractor] Attempting spawn launch
++++++++++++++++++++++++++++++++++++++++++++++++
+++ Start: Spawn launch
++++++++++++++++++++++++++++++++++++++++++++++++
[Utils] Closing logging file.
Now the situation is inverted, the "server" JVM is not found and the "client" is there (as expected).
JWrapper is still unable to load it though, and it still doesn't provide any useful information for why it can't be loaded.
The main difference now is that, even though JWrapper can't load the client JVM, it will try a legacy spawn instead, which worked well in my case.

Related

Could not load file or assembly Newtonsoft.Json when running app from the dotnet publish output folder

I am finding a problem with Newtonsoft.Json library throwing a
System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The system cannot find the file specified
when running an app as a Docker container and I'd like to know why this happens and why dependency management does not work smoothly.
I use .NET 5.
I have a library MyLibrary.A that explicitly uses Newtonsoft.Json 13.0.1 for serializing and deserializing json.
I have a different library MyLibrary.B that wraps a MassTransit.AmazonSQS library. This MassTransit library also uses Newtonsoft.Json, but probably a different version.
If I don't do anything explicit, it seems the MassTransit dependency shows the Newtonsoft.Json 11.0.2. If at MyLibrary.B I explicitly add Newtonsoft.Json 13.0.1, even though I don't explicitly use it, then MassTransit seems to be happy with using this newest Newtonsoft.Json 13.0.1
Now, I have a web app MyApp that uses MyLibrary.A and MyLibrary.B. It works fine locally, but I use a CI/CD server to generate a Docker image.
Now I spin up this Docker image as a container locally (as a Docker Compose) and I get the error
Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The system cannot find the file specified.
It complains about a version that does not even exist. There is no 13.0.0.0, This library seems to go from 12.0.3 to 13.0.1.
I am now going through all my libraries and making sure they all use Newtonsoft.Json 13.0.1 explicitly. And when I detect that some of them use some third party that relies on Newtonsoft.Json I add explicitly the very same version, so that I can get everywhere the 13.0.1 version.
UPDATE 1: My workaround didn't work. I don't know what else to try.
I have even added the Newtonsoft.Json 13.0.1 explicitly to my webapp so I was hoping that at least at runtime it has it available.
Also, if I run my web up locally as a standard kestrel AspNetCore app (.NET 5) it launches properly. What is going on? Why is my docker container complaining about Newtonsoft.Json 13.0.0.0 not being found?
These are the traces when attempting to run as a Docker container
docker run -p 8080:80 \
> -e ASPNETCORE_ENVIRONMENT=Production \
> registry.gitlab.com/sample/foo-integration-service:latest
Unable to find image 'registry.gitlab.com/sample/foo-integration-service:latest' locally
latest: Pulling from sample/foo-integration-service
07aded7c29c6: Pull complete
97aff7269a5a: Pull complete
633b89d569a5: Pull complete
bd0e639a2ac9: Pull complete
a9a5571a369e: Pull complete
9569d825ee3a: Pull complete
Digest: sha256:5499b40392512f1731890ccf1ee13507769b733ee2f30c95d281f0550f7a892e
Status: Downloaded newer image for registry.gitlab.com/sample/foo-integration-service:latest
Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The system cannot find the file specified.
File name: 'Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitConstructor(ConstructorCallSite constructorCallSite, RuntimeResolverContext context)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSiteMain(ServiceCallSite callSite, TArgument argument)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitDisposeCache(ServiceCallSite transientCallSite, RuntimeResolverContext context)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSite(ServiceCallSite callSite, TArgument argument)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitConstructor(ConstructorCallSite constructorCallSite, RuntimeResolverContext context)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSiteMain(ServiceCallSite callSite, TArgument argument)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitDisposeCache(ServiceCallSite transientCallSite, RuntimeResolverContext context)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSite(ServiceCallSite callSite, TArgument argument)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitConstructor(ConstructorCallSite constructorCallSite, RuntimeResolverContext context)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSiteMain(ServiceCallSite callSite, TArgument argument)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitDisposeCache(ServiceCallSite transientCallSite, RuntimeResolverContext context)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSite(ServiceCallSite callSite, TArgument argument)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitConstructor(ConstructorCallSite constructorCallSite, RuntimeResolverContext context)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSiteMain(ServiceCallSite callSite, TArgument argument)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitCache(ServiceCallSite callSite, RuntimeResolverContext context, ServiceProviderEngineScope serviceProviderEngine, RuntimeResolverLock lockType)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitRootCache(ServiceCallSite singletonCallSite, RuntimeResolverContext context)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSite(ServiceCallSite callSite, TArgument argument)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitIEnumerable(IEnumerableCallSite enumerableCallSite, RuntimeResolverContext context)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSiteMain(ServiceCallSite callSite, TArgument argument)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitCache(ServiceCallSite callSite, RuntimeResolverContext context, ServiceProviderEngineScope serviceProviderEngine, RuntimeResolverLock lockType)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitRootCache(ServiceCallSite singletonCallSite, RuntimeResolverContext context)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSite(ServiceCallSite callSite, TArgument argument)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.Resolve(ServiceCallSite callSite, ServiceProviderEngineScope scope)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.DynamicServiceProviderEngine.<>c__DisplayClass1_0.<RealizeService>b__0(ServiceProviderEngineScope scope)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngine.GetService(Type serviceType, ServiceProviderEngineScope serviceProviderEngineScope)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope.GetService(Type serviceType)
at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetService[T](IServiceProvider provider)
at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.RunAsync(IHost host, CancellationToken token)
at Microsoft.Extensions.Hosting.HostingAbstractionsHostExtensions.Run(IHost host)
at foo.ItgService.Program.Main(String[] args) in /builds/sample/foo-integration-service/src/foo.ItgService/Program.cs:line 10
UPDATE 2: I decided to match MassTransit dependency Newtonsoft.Json 11.0.2 everywhere in my libraries.
The problem remains.
The error is now
Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=11.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The system cannot find the file specified.
I don't get it. All my dependencies of Newtonsoft.Json are now 11.0.2 and still it complains. I'll add this version explicitly (even though I don't directly need it) at the web app main assembly and see if it still complains about it.
UPDATE 3: Still same problem after adding Newtonsoft.Json 11.0.2 to all my libraries and after adding that very same dependency to my web app assembly as a dependency.
As per Chris' comment I have now a .dockerignore.
bin/
obj/
The way I build the image is, with GitLab, with a standard dotnet build, dotnet publish and then copying all the contents of publish folder into the Docker image like this
FROM mcr.microsoft.com/dotnet/aspnet:5.0
COPY publish/ .
EXPOSE 80
ENTRYPOINT ["dotnet", "MyCompany.ItgService.dll"]
More specific, I use Kaniko and this is my .gitlab-ci.yml
image: mcr.microsoft.com/dotnet/sdk:5.0
variables:
GIT_DEPTH: 1000
PUBLISH_OUTPUT_DIR: publish
ENTRYPOINT_DLL: ReplaceMe.dll
CLUSTER_NAME: ReplaceMe
SERVICE_NAME: ReplaceMe
stages:
- build
- test
- publish
- delivery
build:
stage: build
script:
- dotnet restore --no-cache --force
- dotnet build --configuration Release --no-restore
artifacts:
paths:
- test
expire_in: 8 hour
rules:
- if: $CI_COMMIT_TAG
when: never
- when: always
test:
stage: test
services:
- name: localstack/localstack:0.12.17.5
alias: localstack
variables:
# Localstack with SNS and SQS
AWS_DEFAULT_REGION: "us-east-1"
EDGE_PORT: "4566"
SERVICES: "sns,sqs"
before_script:
- rounds=10;
while [ $rounds -gt 0 ]; do
curl http://localstack:4566 && echo OK && break || echo FAIL
rounds=$rounds - 1;
sleep 5;
done;
script: dotnet test --blame --configuration Release
rules:
- if: $CI_COMMIT_TAG
when: never
- exists:
- test/**/*Tests.csproj
publish:
stage: publish
before_script:
- export PATH=$PATH:/root/.dotnet/tools
- dotnet tool install --global GitVersion.Tool --version 5.7.0
- dotnet gitversion
- SEMVER=$(dotnet gitversion -showvariable semver)
- mkdir version
- echo "${SEMVER}" > ./version/semver
- APP_VERSION=$(cat ./version/semver)
script:
- dotnet publish -c Release -o $PUBLISH_OUTPUT_DIR -p:Version=$APP_VERSION
artifacts:
paths:
- $PUBLISH_OUTPUT_DIR/
- version/
expire_in: 8 hour
rules:
- if: $CI_COMMIT_TAG
when: never
- when: always
container_registry:
stage: delivery
image:
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
before_script:
- IMAGE_TAG=$(cat ./version/semver)
- echo "bin/" > $CI_PROJECT_DIR/.dockerignore
- echo "obj/" > $CI_PROJECT_DIR/.dockerignore
- echo "FROM mcr.microsoft.com/dotnet/aspnet:5.0" > $CI_PROJECT_DIR/Dockerfile
- echo "COPY $PUBLISH_OUTPUT_DIR/ ." >> $CI_PROJECT_DIR/Dockerfile
- echo "EXPOSE 80" >> $CI_PROJECT_DIR/Dockerfile
- echo "ENTRYPOINT [\"dotnet\", \"$ENTRYPOINT_DLL\"]" >> $CI_PROJECT_DIR/Dockerfile
- cat $CI_PROJECT_DIR/Dockerfile
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
- cat /kaniko/.docker/config.json
script:
- /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:latest --destination $CI_REGISTRY_IMAGE:$IMAGE_TAG
rules:
- if: $CI_COMMIT_TAG
when: never
- when: always
I don't know if the dotnet publish is messing something up for docker or whether there is some flaw in my process (it works fine for all other services). What might be the problem?
I can see Newtonsoft.Json.dll among the files produced by dotnet publish along with MassTransit.AmazonSqsTransport and all others that are supposedly being copied properly to the Docker image.
Also, If I open the .deps.json I can see all references to Newtonsoft.Json are 11.0.2, so no version conflict anymore (I think!).
I'm out of ideas.
UPDATE 4
I've just cleared all my local nuget packages (using Ubuntu)
dotnet nuget locals all --clear
Clearing NuGet HTTP cache: /home/diegosasw/.local/share/NuGet/v3-cache
Clearing NuGet global packages folder: /home/diegosasw/.nuget/packages/
Clearing NuGet Temp cache: /tmp/NuGetScratch
Clearing NuGet plugins cache: /home/diegosasw/.local/share/NuGet/plugins-cache
Local resources cleared.
An interesting thing is that when I restore dependencies after that on my project
dotnet restore
I can see at /home/diegosasw/.nuget/packages/newtonsoft.json
that there are versions 11.0.2 and 9.0.1
So I guess somewhere somehow a sub-dependency is using Newtonsoft 9.0.1, even though there is no trace of a Newtonsoft.Json 9.0.1 in my the *.deps.json that my dotnet publish produces, and I'm wondering whether this is related to my problem, maybe because that's the assembly being loaded and the 11 is being ignored?
UPDATE 5
I've just seen that the Newtonsoft.Json 9.0.1 is being used by some test project, because I can trace it at coverlet.collector.deps.json under coverlet.core 1.0.0 and the Microsoft.Extensions.DependencyModel 2.1.0
I guess it's not the cause of my problem then.
Also I've verified with docker export $(docker ps -lq) -o foo.tar that the container has the Newtonsoft.Json.dll.
I would like to understand why is this happening and learn how to better troubleshoot these kind of things.
UPDATE 6 (4 Oct)
I don't think the problem is with Docker. I think the problem is likely with dotnet publish or something I'm missing or doing wrong.
I have left Docker outside since I didn't see anything wrong there.
I tried to simply do a
dotnet publish -c Release -o publish
and execute the app in that
publish folder with dotnet MyCompany.ItgService.dll to reproduce the exception.
But before publishing, when I run the application with a
dotnet run -c Release --project src/Rubiko.ItgService
I don't get that exception.
See https://github.com/dotnet/sdk/issues/21716 for full details, traces, tree structure, etc.
Summary
The questions are:
Why dotnet publish does not seem to produce everything my app needs to run?
Why does it complain at runtime about an assembly that is there?
$ ls publish/ | grep Newtonsoft
Newtonsoft.Json.Bson.dll*
Newtonsoft.Json.dll*
FINAL UPDATE: Problem solved. See my own response where info on how to properly troubleshoot these kind of issues and how I solved it by ensuring my test projects (that use different version of the library) don't publish artifacts and overwrite the desired dependency assembly.
I solved the mystery. It had nothing to do with Docker. It kind of had something to do with dotnet publish but the SDK works well.
The problem was, as initially suspected, with a version conflict. When publishing with dotnet publish -c Release -o publish I could see the Newtonsoft.Json.dll there. But the following made me suspicious
ls publish/ -al | grep Newtonsoft
-rwxrw-r-- 1 diegosasw 89K mar 22 2017 Newtonsoft.Json.Bson.dll*
-rwxrw-r-- 1 diegosasw 641K mar 24 2018 Newtonsoft.Json.dll*
2018 seems a bit old for that version. What if.. that Newtonsoft.Json assembly being published wasn't the version 11.0.2 after all?
I updated all my libraries to match MassTransit dependency on Newtonsoft 11.0.2 but my findings on Update 4 made me think there was some other project depending indirectly on Newtonsoft.Json 9.0.1, and that's why I could see that nuget package being cached locally.
If, somehow, the assembly being published is not the expected Newtonsoft.Json 11.0.2 but the Newtonsoft.Json 9.0.1, the error would make sense when complaining about not finding the assembly Newtonsoft.Json 11.0.2
Bingo!
I installed exiftool in my Ubuntu to check dll and exe versions.
sudo apt install libimage-exiftool-perl
I run the following
$ exiftool publish/Newtonsoft.Json.dll
ExifTool Version Number : 11.88
File Name : Newtonsoft.Json.dll
Directory : publish
File Size : 465 kB
File Modification Date/Time : 2021:07:19 19:52:18+02:00
File Access Date/Time : 2021:10:04 12:53:14+02:00
File Inode Change Date/Time : 2021:10:04 12:44:39+02:00
File Permissions : rwxrw-r--
File Type : Win32 DLL
File Type Extension : dll
MIME Type : application/octet-stream
Machine Type : Intel 386 or later, and compatibles
Time Stamp : 2016:06:13 13:05:00+02:00
Image File Characteristics : Executable, Large address aware, DLL
PE Type : PE32
Linker Version : 48.0
Code Size : 465920
Initialized Data Size : 2048
Uninitialized Data Size : 0
Entry Point : 0x738b6
OS Version : 4.0
Image Version : 0.0
Subsystem Version : 4.0
Subsystem : Windows command line
File Version Number : 9.0.1.19813
Product Version Number : 9.0.1.0
File Flags Mask : 0x003f
File Flags : (none)
File OS : Win32
Object File Type : Dynamic link library
File Subtype : 0
Language Code : Neutral
Character Set : Unicode
Comments : Json.NET is a popular high-performance JSON framework for .NET
Company Name : Newtonsoft
File Description : Json.NET .NET Standard 1.0
File Version : 9.0.1.19813
Internal Name : Newtonsoft.Json.dll
Legal Copyright : Copyright © James Newton-King 2008
Legal Trademarks :
Original File Name : Newtonsoft.Json.dll
Product Name : Json.NET
Product Version : 9.0.1
Assembly Version : 9.0.0.0
and as you can see, the published assembly is Newtonsoft.Json 9.0.1. A mix of relief invades me.
I went to my test projects and added the following to the *.csproj
<IsPublishable>false</IsPublishable>
and
rm -rd publish
dotnet publish -c Release -o publish
Moment of truth
$ exiftool publish/Newtonsoft.Json.dll
ExifTool Version Number : 11.88
File Name : Newtonsoft.Json.dll
Directory : publish
File Size : 641 kB
File Modification Date/Time : 2018:03:24 18:44:14+01:00
File Access Date/Time : 2021:10:04 12:44:38+02:00
File Inode Change Date/Time : 2021:10:04 12:57:29+02:00
File Permissions : rwxrw-r--
File Type : Win32 DLL
File Type Extension : dll
MIME Type : application/octet-stream
Machine Type : Intel 386 or later, and compatibles
Time Stamp : 2098:12:14 20:33:48+01:00
Image File Characteristics : Executable, Large address aware, DLL
PE Type : PE32
Linker Version : 48.0
Code Size : 653824
Initialized Data Size : 2048
Uninitialized Data Size : 0
Entry Point : 0xa16b6
OS Version : 4.0
Image Version : 0.0
Subsystem Version : 4.0
Subsystem : Windows command line
File Version Number : 11.0.2.21924
Product Version Number : 11.0.2.0
File Flags Mask : 0x003f
File Flags : (none)
File OS : Win32
Object File Type : Dynamic link library
File Subtype : 0
Language Code : Neutral
Character Set : Unicode
Comments : Json.NET is a popular high-performance JSON framework for .NET
Company Name : Newtonsoft
File Description : Json.NET .NET Standard 2.0
File Version : 11.0.2.21924
Internal Name : Newtonsoft.Json.dll
Legal Copyright : Copyright © James Newton-King 2008
Legal Trademarks :
Original File Name : Newtonsoft.Json.dll
Product Name : Json.NET
Product Version : 11.0.2
Assembly Version : 11.0.0.0
Now the assembly published is the expected 11.0.2.
I verify that running my app from the publish folder now works fine!
cd publish
dotnet MyCompany.ItgService.dll
Just use the version that MassTransit depends upon, which is much earlier than v13. Upgrading past that without the proper assembly redirects is likely causing your issue.
I had a very similar problem with the Newtonsoft package in my .NET core 3.1 web application (not using docker). Neither in my main project (web app) nor in the class library (implemented for sending emails) I explicitly referenced Newtonsoft.Json.dll. Running locally on my machine a dotnet publish created the web app correctly with Newtonsoft.Json.dll (v11.0.2). This is the correct dll, I have checked it in the *.deps.json.
Same command on my windows server which I use for the build step in my deplyoment pipeline created a different Newtonsoft.Json.dll (v9.0.1). With this one my web app did not run correctly (same error like you).
What worked for me: I deleted the folder C:\Program Files\dotnet manually. Then I reinstalled the latest .NET SDK x64 on my build server. And BOOM, correct Newtonsoft.Json.dll (v11.0.2) was published. Before that I deinstalled an old Visual Studio 2019 instance and installed a fresh Visual Studio 2022 Enterprise IDE. Apparently, this does not replace the dotnet folder and has no effect. So my conclusion is that the dotnet.exe was buggy I had installed on my server and did not restore correctly the nuget package for Newtonsoft.

DllNotFoundException using SkiaSharp 1.68 on Linux

Using SkiaSharp 1.68.0 with .NET Core 2.2 on Linux and get this error when trying to use Decode on a jpeg-memory-stream (same code works on Windows):
System.TypeInitializationException: The type initializer for 'SkiaSharp.SKAbstractManagedStream' threw an exception. ---> System.DllNotFoundException: Unable to load shared library 'libSkiaSharp' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibSkiaSharp: cannot open shared object file: No such file or directory
at SkiaSharp.SkiaApi.sk_managedstream_set_delegates(IntPtr pRead, IntPtr pPeek, IntPtr pIsAtEnd, IntPtr pHasPosition, IntPtr pHasLength, IntPtr pRewind, IntPtr pGetPosition, IntPtr pSeek, IntPtr pMove, IntPtr pGetLength, IntPtr pCreateNew, IntPtr pDestroy)
at SkiaSharp.SKAbstractManagedStream..cctor()
--- End of inner exception stack trace ---
at SkiaSharp.SKAbstractManagedStream..ctor(Boolean owns)
at SkiaSharp.SKManagedStream..ctor(Stream managedStream, Boolean disposeManagedStream, Boolean owns)
at SkiaSharp.SKManagedStream..ctor(Stream managedStream, Boolean disposeManagedStream)
at SkiaSharp.SKCodec.WrapManagedStream(Stream stream)
at SkiaSharp.SKCodec.Create(Stream stream, SKCodecResult& result)
at SkiaSharp.SKCodec.Create(Stream stream)
at SkiaSharp.SKBitmap.Decode(Stream stream)
The inner-most error message seem to be "No such file or directory" which is strange since I'm decoding a memory-stream. This works on Windows and it have worked on Linux before I upgraded to .NET Core 2.2 and latest SkiaSharp.
I have tried setting the LD_DEBUG env variable as suggested in the error message but that didn't do much. Not sure what to set it to really. Tried 'all' but that didn't result in any more detailed log.
Found a thread that suggests installing SkiaSharp.NativeAssets.Linux as a solution, but unfortunately that didn't help. Do I need to target Linux-x64 runtime when building/publishing? Have tried different combinations but couldn't detect any difference. (I'm building with dotnet cli in a Docker-file on Linux over ssh with putty. Pretty much default Docker-file as generated by VS:latest)
Another suggestion was to install libSkiaSharp.so manually and also apt-get install libfontconfig1, but unfortunately apt-get is not available on Synology DSM.
Installing Linux dependency NuGet Package will solve this issue
SkiaSharp.NativeAssets.Linux.NoDependencies
https://www.nuget.org/packages/SkiaSharp.NativeAssets.Linux.NoDependencies
I had the same problem running SkiaSharp with .Net Core 2.2 on Linux.
First, I installed the NuGet package SkiaSharp.NativeAssets.Linux (that you mention above) and made sure that the libSkiaSharp.so file was copied into the same directory as the rest of the DLLs.
I still received the error.
Next, I connected a shell to my container and I listed the dependencies using the command:
ldd libSkiaSharp.so
I found out that I was missing libfreetype6 and libfontconfig1.
As my environment uses Docker, I simply added some commands to install these extra dependencies in my docker file:
FROM microsoft/dotnet:aspnetcore-runtime
RUN apt-get update
RUN apt-get install -y libfreetype6
RUN apt-get install -y libfontconfig1
Now the application works.
Can you try adding these commands to your Docker file?

Unable to launch JWrapper under MacOS High Sierra

We have an application that, up until today's High Sierra update, was running fine under MacOS. Now it will update, but not run the application.
We also note that JWrapper.app also doesn't run under High Sierra.
Here is a log snippet - does anyone have a clue as to what is wrong?
...
+0 ++++++++++++++++++++++++++++++++++++++++++++++++
+0 +++ Start: Launching
+0 ++++++++++++++++++++++++++++++++++++++++++++++++
+0 [Extractor] Launching 'JWrapper-JWrapper-00049034758-complete' from master folder '/Users/user/Library/Application Support/JWrapper-APPNAME (UAT)' of class 0 using JRE 'Mac64JRE'
+1 [PickFolder] Folder JWrapper-Mac64JRE-00054617449-complete.plugin matches Mac64JRE with version 54617449
+0 [PickFolder] Set latest to 54617449 JWrapper-Mac64JRE-00054617449-complete.plugin
+0 [PickFolder] Folder JWrapper-Mac64JRE-00054617449-complete matches Mac64JRE with version 54617449
+0 [Extractor] Using private JRE JWrapper-Mac64JRE-00054617449-complete.plugin
+0 [Utils] File does NOT exist: /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWrapper-Mac64JRE-00054617449-complete.plugin/bin/APPNAME (UAT)
+0 [Extractor] Copying FILE /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWrapper-Mac64JRE-00054617449-complete.plugin/bin/APPNAME (UAT)
+0 [Extractor] *************************** Unable to open source file for copy /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWrapper-Mac64JRE-00054617449-complete.plugin/bin/java
+0 *******************************************
+0 Error setting app binary executable!
+0 *******************************************
+0 [Extractor] JRE LSO file is /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWApps/JRE-LastSuccessfulOptions-JWrapper-Mac64JRE-00054617449-complete.plugin
+0 [Extractor] Building classpath
+0 [Extractor] Creating launch properties
+0 [Extractor] Checking LSO file
+0 [Extractor] Reading /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWApps/JRE-LastSuccessfulOptions-JWrapper-Mac64JRE-00054617449-complete.plugin
+0 [Utils] File does NOT exist: /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWApps/JRE-LastSuccessfulOptions-JWrapper-Mac64JRE-00054617449-complete.plugin
+0 *******************************************
+0 JRE LSO file does not exist
+0 *******************************************
+0 [Extractor] Writing launch properties file
+0 [Extractor] Writing launch properties to /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWrapper-JWrapper-00049034758-complete/JWLaunchProperties-1506477183962-19
+0 [Extractor] Launch properties length is 868
+0 [Extractor] Writing to file
+1 [Extractor] Finished writing launch properties file
+0 [Extractor] Reading 0 extra args
+0 [Extractor] Read JRE compatibility class jwrapper.updater.GenericUpdaterJreVerifierLaunch
+0 [Extractor] Appending 1 command line args
+0 [Extractor] Executable: /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWrapper-Mac64JRE-00054617449-complete.plugin/bin/APPNAME (UAT)
+0 [Extractor] Argument 0: /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWrapper-Mac64JRE-00054617449-complete.plugin/bin/APPNAME (UAT)
+0 [Extractor] Argument 1: -cp
+0 [Extractor] Argument 2: /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWrapper-JWrapper-00049034758-complete/jwrapperlib/jwstandalonelaunch.jar
+0 [Extractor] Argument 3: jwrapper.updater.GenericUpdaterLaunch
+0 [Extractor] Argument 4: /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWrapper-JWrapper-00049034758-complete/JWLaunchProperties-1506477183962-19
+0 [Extractor] Argument 5: -psn_0_2048500
+0 [Extractor] This is a newer extractor... launchclass is 0
+0 [Extractor] JRE folder is /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWrapper-Mac64JRE-00054617449-complete.plugin
+0 [BundleLoader] Creating jre path URL for path /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWrapper-Mac64JRE-00054617449-complete.plugin.plugin
+0 [BundleLoader] Created NSURL
+0 [BundleLoader] Bundle is null?+0 [Extractor] Adjusted JRE folder is /Users/user/Library/Application Support/JWrapper-APPNAME (UAT)/JWrapper-Mac64JRE-00054617449-complete.plugin.plugin/Contents/Home
+0 [Extractor] Force spawn is 0 so attempting to launch via JNI
+0 ++++++++++++++++++++++++++++++++++++++++++++++++
+0 +++ Start: JNI Launch
+0 ++++++++++++++++++++++++++++++++++++++++++++++++
+0 [JNILaunch] [pid=9416] [mainThread=0]
+0 [JNILaunch] [ERROR] Could not load dynamic library!
+0 [JNILaunch] [ERROR] Unable to load JRE library!
+0 [Extractor] Return code for JNI launch was 1
+0 ------------------------------------------------
+0 --- End: JNI Launch
+0 ------------------------------------------------
+0 [Extractor] JNI launch failed. Attempting legacy spawn instead
+0 [Extractor] Attempting spawn launch
+0 ++++++++++++++++++++++++++++++++++++++++++++++++
+0 +++ Start: Spawn launch
+0 ++++++++++++++++++++++++++++++++++++++++++++++++
+0 [Utils] Closing logging file.
The answer to this is simple - update the JRE to the latest Oracle JRE, which at time of writing was 1.8.0_144.
We note that the jwrapper version we are using (49034758) is the latest version you can run without purchasing a license. I would seriously think twice before paying for this product.

Dealing with "HTTP request timed out. Exiting." when building a large aspnet project for Docker

I have a multi-project aspnet solution using MVC6
The Solution file is split into three projects
sln
+---- Model
+---- API
+---- Web
The Docker file lives in the same folder as the SLN file and has the following content
FROM microsoft/aspnet
COPY . /app
WORKDIR /app/Web
RUN ["dnu", "restore"]
EXPOSE 5004
ENTRYPOINT ["dnx", ".", "kestrel" ]
The issue when I run docker build -t myapp . from the powershell command line is the build process begins to time out.
PS C:\www\MyApp> docker build -t myapp .
Sending build context to Docker daemon 19.11 MB
Step 0 : FROM microsoft/aspnet
---> 0835b01cd4f8
Step 1 : COPY . /app
---> Using cache
---> 56c449a3d847
Step 2 : WORKDIR /app/Web
---> Using cache
---> 8f43b8786452
Step 3 : RUN dnu restore
---> Running in d43e0c4b42c8
Microsoft .NET Development Utility Mono-x64-1.0.0-beta7-15532
GET https://api.nuget.org/v3/index.json
OK https://api.nuget.org/v3/index.json 555ms
Restoring packages for /app/Web/project.json
GET https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.aspnet.diagnostics/index.json
GET https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.aspnet.mvc/index.json
GET https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.aspnet.mvc.taghelpers/index.json
GET https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.aspnet.server.iis/index.json
GET https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.aspnet.server.weblistener/index.json
GET https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.aspnet.staticfiles/index.json
GET https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.aspnet.tooling.razor/index.json
GET https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.framework.configuration.json/index.json
GET https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.framework.logging/index.json
GET https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.framework.logging.console/index.json
GET https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.visualstudio.web.browserlink.loader/index.json
OK https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.aspnet.diagnostics/index.json 6436ms
[... AFTER HUNDREDS OF LINES OF INITIAL SUCCESS ...]
disaster strikes!
GET https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.win32.registry/4.0.0-beta-23109/microsoft.win32.registry.4.0.0-beta-23109.nupkg
Warning: FindPackagesById: Microsoft.Framework.Runtime.Roslyn.Common
HTTP request timed out. Retrying.
GET https://az320820.vo.msecnd.net/v3-flatcontainer/system.io.filesystem/index.json
Warning: FindPackagesById: Microsoft.Framework.Runtime.Roslyn.Abstractions
HTTP request timed out. Retrying.
GET https://az320820.vo.msecnd.net/v3-flatcontainer/system.resources.resourcemanager/index.json
Warning: FindPackagesById: System.Threading.Tasks.Parallel
HTTP request timed out. Retrying.
GET https://az320820.vo.msecnd.net/v3-flatcontainer/system.diagnostics.debug/index.json
Warning: FindPackagesById: Microsoft.AspNet.Antiforgery
HTTP request timed out. Retrying.
[ ... RESULTING IN MANY LINES OF ... ]
GET https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.win32.primitives/index.json
Error: DownloadPackageAsync: https://az320820.vo.msecnd.net/v3-flatcontainer/microsoft.aspnet.http.abstractions/1.0.0-beta6/microsoft.aspnet.http.abstractions.1.0.0-beta6.nupkg
HTTP request timed out. Exiting.
----------
System.Threading.Tasks.TaskCanceledException: A task was canceled.
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x00000] in <filename unknown>:0
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x00000] in <filename unknown>:0
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x00000] in <filename unknown>:0
at System.Runtime.CompilerServices.TaskAwaiter`1[System.Net.Http.HttpResponseMessage].GetResult () [0x00000] in <filename unknown>:0
at System.Net.Http.HttpClientHandler+<SendAsync>c__async0.MoveNext () [0x00000] in <filename unknown>:0
--- End of stack trace from previous location where exception was thrown ---
[ ... AND EVENTUALLY ... ]
----------
Restore failed
A task was canceled.
NuGet Config files used:
/root/.config/NuGet/NuGet.Config
Feeds used:
https://az320820.vo.msecnd.net/v3-flatcontainer/
GET https://az320820.vo.msecnd.net/v3-flatcontainer/system.security.cryptography.x509certificates/index.json
SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.
The command 'dnu restore' returned a non-zero code: 1
I've tried hunting about for answers on this and doing things like restarting the docker machine or deleting and rebuilding it (in kitematic), but even if those solutions DID work (they don't) that solution seems less than ideal.
Note that I've also attempted to view the urls that are timing out, from the very same machine that is timing out and they do work from windows.
I assume that may mean that the virtualbox docker machine is perhaps timing out, saturating the number of connections it can open or something
The docker image is the default boot2docker linux instance that comes with the docker toolbox.
It is running on windows 10.
Alternatively, if I run the same setup and commands on a new aspnet project (as created using the yo aspnet generator), docker does indeed successfully build the project.
Any help in figuring out how to build a docker image would be very much appreciated.

Saving a file to 'C:\Windows\System32\dns' causes 'Could not find a part of the path' error

I've written a windows forms (.net 4) application that needs to write a file to the folder 'C:\Windows\System32\dns'. When this line of code runs:
File.WriteAllText(dnsFileLocation, luxDns)
I get the following error, does anyone know why?
Note: This happens even if I run the application as administrator!
***** Exception Text *******
System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Windows\System32\dns\lux2.dns'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
at System.IO.StreamWriter.CreateFile(String path, Boolean append)
at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize)
at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding)
at System.IO.File.InternalWriteAllText(String path, String contents, Encoding encoding)
at System.IO.File.WriteAllText(String path, String contents)
at DnsServerUpdater.Main.Main_Load(Object sender, EventArgs e)
at System.EventHandler.Invoke(Object sender, EventArgs e)
at System.Windows.Forms.Form.OnLoad(EventArgs e)
at System.Windows.Forms.Form.OnCreateControl()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.Form.WmShowWindow(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.261 (RTMGDR.030319-2600)
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
DnsServerUpdater
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/web/dns/DnsServerUpdater.exe
----------------------------------------
Microsoft.VisualBasic
Assembly Version: 10.0.0.0
Win32 Version: 10.0.30319.1 built by: RTMRel
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
System
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.261 built by: RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.233 built by: RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.235 built by: RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.276 built by: RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Runtime.Remoting
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 (RTMRel.030319-0100)
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
***** JIT Debugging *******
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
For example:
<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>
When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
Are you running 64bit windows ? If yes then that's probably your issue as you will get redirected in another directory.
You will need to implement
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365743%28v=vs.85%29.aspx and
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365745%28v=vs.85%29.aspx
in order to temporarily disable the 64bit redirection in order to access that folder.
Can you check if the directory exists? Since system32 is a windows folder, to create files and folders inside it requires special rights. Does the user who is running the win forms app have rights to create folder/file inside the system32 folder?

Resources