I am using Linux containers on the latest Windows build Windows 10 2004 and enabled WSL 2 and Docker Desktop 2.3.0.3 (45519).
I right click the docker-compose file, and select Set as Startup Project.
I then hit F5 to debug.
I can see the image running with docker ps however breakpoints are not being hit.
I cannot view Logs (on the Visual Studio Containers window) as it says:
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.0' was not found.
- No frameworks were found.
You can resolve the problem by installing the specified framework and/or SDK.
The specified framework can be found at:
- https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=3.1.0&arch=x64&rid=debian.10-x64
I have installed the SDKs from the link given above.
Build output is below:
1>------ Build started: Project: Libertas.Host.Tickers.ScheduledTasks, Configuration: Debug Any CPU ------
1>Libertas.Host.Tickers.ScheduledTasks -> C:\Users\User\Source\Repos\myrepo\Libertas\src\Libertas.Host.Tickers.ScheduledTasks\bin\Debug\netcoreapp3.1\Libertas.Host.Tickers.ScheduledTasks.dll
1>docker build -f "C:\Users\User\Source\Repos\myrepo\Libertas\src\Libertas.Host.Tickers.ScheduledTasks\Dockerfile" --force-rm -t libertashosttickersscheduledtasks:dev --target base --label "com.microsoft.created-by=visual-studio" --label "com.microsoft.visual-studio.project-name=Libertas.Host.Tickers.ScheduledTasks" "C:\Users\User\Source\Repos\myrepo\Libertas\src"
1>Sending build context to Docker daemon 1.362MB
1>
1>Step 1/4 : FROM mcr.microsoft.com/dotnet/core/runtime:3.1-buster-slim AS base
1> ---> 86a2e7d45948
1>Step 2/4 : WORKDIR /app
1> ---> Running in d1ed1740d43e
1>Removing intermediate container d1ed1740d43e
1> ---> 90bd1703e28d
1>Step 3/4 : LABEL com.microsoft.created-by=visual-studio
1> ---> Running in 2626d5865d89
1>Removing intermediate container 2626d5865d89
1> ---> da74703374d2
1>Step 4/4 : LABEL com.microsoft.visual-studio.project-name=Libertas.Host.Tickers.ScheduledTasks
1> ---> Running in 7a381e7ea47a
1>Removing intermediate container 7a381e7ea47a
1> ---> fd2dd439cce6
1>Successfully built fd2dd439cce6
1>Successfully tagged libertashosttickersscheduledtasks:dev
1>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.
1>docker rm -f 9ff95181e06801ed3d4b4d5743397604b743d77c840f2047fb2caee046e5d8eb
1>Error: No such container: 9ff95181e06801ed3d4b4d5743397604b743d77c840f2047fb2caee046e5d8eb
1>docker run -dt -v "C:\Users\User\vsdbg\vs2017u5:/remote_debugger:rw" -v "C:\Users\User\Source\Repos\myrepo\Libertas\src\Libertas.Host.Tickers.ScheduledTasks:/app" -v "C:\Users\User\Source\Repos\myrepo\Libertas\src:/src/" -v "C:\Users\User\AppData\Roaming\Microsoft\UserSecrets:/root/.microsoft/usersecrets:ro" -v "C:\Users\User\.nuget\packages\:/root/.nuget/fallbackpackages" -e "DOTNET_USE_POLLING_FILE_WATCHER=1" -e "NUGET_PACKAGES=/root/.nuget/fallbackpackages" -e "NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages" --name Libertas.Host.Tickers.ScheduledTasks_1 --entrypoint tail libertashosttickersscheduledtasks:dev -f /dev/null
1>ba95df9d32d6a0af07b1eab32af606131e075b2afff664c4003dbe3eae349543
========== Build: 1 succeeded, 0 failed, 6 up-to-date, 0 skipped ==========
My Dockerfile is below:
#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/core/runtime:3.1-buster-slim AS base
WORKDIR /app
FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY ["Libertas.Host.Tickers.ScheduledTasks/Libertas.Host.Tickers.ScheduledTasks.csproj", "Libertas.Host.Tickers.ScheduledTasks/"]
COPY ["Libertas.Application.Tickers.ScheduledTasks/Libertas.Application.Tickers.ScheduledTasks.csproj", "Libertas.Application.Tickers.ScheduledTasks/"]
COPY ["PolygonIo.WebSocket/PolygonIo.WebSocket.csproj", "PolygonIo.WebSocket/"]
RUN dotnet restore "Libertas.Host.Tickers.ScheduledTasks/Libertas.Host.Tickers.ScheduledTasks.csproj"
COPY . .
WORKDIR "/src/Libertas.Host.Tickers.ScheduledTasks"
RUN dotnet build "Libertas.Host.Tickers.ScheduledTasks.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "Libertas.Host.Tickers.ScheduledTasks.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Libertas.Host.Tickers.ScheduledTasks.dll"]
I am unable to hit any breakpoints or even confirm if the app is running. I have a Generic Host app, and I don't even hit the breakpoint of the first line within public static void Main(string[] args).
Pointers much appreciated.
UPDATE AND FIX
So this was the smoking gun, in particular as this was a console application, and not a AspNetCore app.
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.0' was not found.
- No frameworks were found.
You can resolve the problem by installing the specified framework and/or SDK.
The specified framework can be found at:
- https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=3.1.0&arch=x64&rid=debian.10-x64
I found one of my referenced libraries had a reference to Grpc.AspNetCore.
Once i moved this code out, it was able to run (I can confirm before the container instance was not running), with full debugging.
It compiled OK, the container ran, the application within the container never seemed to launch.
QUESTION
I would like to get to the bottom of why, as i don't fully understand how this fixed everything and what can be done to avoid in future (seems any console app that references a library that accidentally or otherwise references an AspNetCore dependency could have the same issue).
I had run into a similar problem... well, I think that the reasons are quite similar, in my case, I could not do anything, I could not even build the project, I had compiling errors, 'simple' ones... lol... let's say that using system; was erring and some other libraries that are there by default.
After a lot of investigation, I found out that my project was in net standard 2.0, but one of the nuget packages was for net standard 2.1, removing that package and finding a way to fix that part of the code resolved the problem.
The reason I believe was similar to what you are after, when adding the libraries, you are adding external code, external code that you don't control, so if the external library was referencing to another library that was not compatible with your project, like in my case, so I believe that the libraries were fighting to decide if it was meant to be a console or a web server app, have you tried to see the process that was created?
I also had a look at the library that you are mentioning (https://www.nuget.org/packages/Grpc.AspNetCore) and then click on dependencies and then there is this package:
Grpc.AspNetCore.Server.ClientFactory
which may have caused the crash.
Be careful with nuget packages, they are pretty cool and 'useful' but look at the dependencies, sometimes it is better to do your own code, that was my lesson.
For more details : https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/dependencies
QUESTION I would like to get to the bottom of why, as i don't fully understand how this fixed everything and what can be done to avoid in future (seems any console app that references a library that accidentally or otherwise references an AspNetCore dependency could have the same issue).
In Visual Studio Solution Explorer shows us the dependency tree with Nuget Packages and above that is the Frameworks listing Microsoft.NETCore.App:
This is how we can see the GitHub Repo references AspNetCore:
<FrameworkReference Include="Microsoft.AspNetCore.App" />
How can I stop this from happening?
Check Solution Explorer for Frameworks.
Have Unit Tests on the config and dependencies.
Always review the Package Dependancies you import.
If you're looking for the canonical story it's over here.
The problem Iria discusses can be prevented with NuGet Version ranges and wildcards notation. When referring to package dependencies, NuGet supports using interval notation for specifying version ranges, summarized as follows:
+-----------+---------------+-------------------------------------------------------+
| Notation | Applied rule | Description |
+-----------+---------------+-------------------------------------------------------+
| 1.0 | x ≥ 1.0 | Minimum version, inclusive |
| (1.0,) | x > 1.0 | Minimum version, exclusive |
| [1.0] | x == 1.0 | Exact version match |
| (,1.0] | x ≤ 1.0 | Maximum version, inclusive |
| (,1.0) | x < 1.0 | Maximum version, exclusive |
| [1.0,2.0] | 1.0 ≤ x ≤ 2.0 | Exact range, inclusive |
| (1.0,2.0) | 1.0 < x < 2.0 | Exact range, exclusive |
| [1.0,2.0) | 1.0 ≤ x < 2.0 | Mixed inclusive minimum and exclusive maximum version |
| (1.0) | invalid | invalid |
+-----------+-------------
When you're adding Packages enforce a version, this way you keep track of your dependancies with different versions (and ultimately versions of the .net framework).
Change the BASE image to use aspnet instead of runtime. The runtime image does not contain the ASPNET libs.
🪲 runtime:3.1-buster-slim
to
👍 aspnet:3.1-buster-slim
This also works for newer releases of .NET.
Related
First time using GCP and I'm trying to upload a .NET project.
I cannot manage to publish the app using the integrated tools from Visual Studio, "Google Cloud Tools" and I get this message "Failed to deploy project to App Engine Flex".
I also tried using Cloud Run or the Google Cloud SDK Shell using gcloud app deploy app.yml but i get this error now:
ERROR
ERROR: build step 0 "gcr.io/cloud-builders/docker" failed: step exited with non-zero status: 1
I know it's coming from the Dockerfile but I don't know how to use and write it. Here it is:
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
COPY./sims/sims.csproj.sims/sims.csproj
COPY .sln./
RUN dotnet restore
COPY . ./
RUN dotnet publish -c Release -o build --no-restore
FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app
COPY --from= build./ build.
ENV ASPNETCORE_URLS = https://:8080
EXPOSE 8080
ENTRYPOINT ["dotnet", "sims.dll"]
Here's my .yaml file in case it might come from here:
runtime: aspnetcore
env: flex
# This sample incurs costs to run on the App Engine flexible environment.
# The settings below are to reduce costs during testing and are not appropriate
# for production use. For more information, see:
# https://cloud.google.com/appengine/docs/flexible/python/configuring-your-app-with-app-yaml
manual_scaling:
instances: 1
resources:
cpu: 1
memory_gb: 0.5
disk_size_gb: 10
Do you have any advice ?
Also, concerning these two files, I don't even know if they're located in the right repository: project tree
Thanks for reading
I have seen a number of similar questions but none seem to represent exactly the issue I am facing. When I create a folder structure as follows:
./
./src
./src/test
Then navigate to ./src/test and run dotnet new webapi -lang c#, this will create a minimal API which works fine. I can also run dotnet publish -c RELEASE -o out /p:Version=1.0.0 without any issues.
When I then try create a docker file at the root level with the following contents:
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
ARG BUILDCONFIG=RELEASE
ARG VERSION=1.0.0
COPY ./src/test/test.csproj ./src/test/
RUN dotnet restore ./src/test/test.csproj
COPY ./src/ ./
WORKDIR ./src/test/
RUN dotnet publish -c $BUILDCONFIG -o out /p:Version=$VERSION
FROM mcr.microsoft.com/dotnet/sdk:6.0
WORKDIR /app
COPY --from=build /src/test/out ./
EXPOSE 5000
ENTRYPOINT ["dotnet", "test.dll"]
I get the following output:
=> ERROR [build 6/6] RUN dotnet publish -c RELEASE -o out /p:Version=1.0.0 2.5s
------
> [build 6/6] RUN dotnet publish -c RELEASE -o out /p:Version=1.0.0:
#11 0.511 Microsoft (R) Build Engine version 17.1.0+ae57d105c for .NET
#11 0.511 Copyright (C) Microsoft Corporation. All rights reserved.
#11 0.511
#11 0.931 Determining projects to restore...
#11 1.153 All projects are up-to-date for restore.
#11 2.400 CSC : error CS5001: Program does not contain a static 'Main' method suitable for an entry point [/src/test/test.csproj]
I tried a few things, including setting the OutputType in the csproj to Exe, DockerDefaultTargetOS to both win/linux and a few other suggestions I found in other threads but ultimately I always get the same error. Any ideas whay might be wrong?
The error message is not explicative.
The real error is on the line of COPY ./src/ ./. With this cmd you copy the CONTENT of the src folder (test) into the ROOT of the container.
It should be COPY ./src/ /src/ or (better) ./src /src
Try to comment out ALL except the first 9 rows, build the container and run
docker run --rm -it <imagename> /bin/sh to see yourself.
Since you try to build an empty folder the compiler raise the error that not found the main method (in reality it not find anything...)
I had the same issue using Visual Studio (Preview) on the Mac. Moved the Dockerfile to the solution root folder then everything worked.
Visual Studio for some reason put the Dockerfile at \Users\robk\git\Play-With-Containers\Play-With-Containers\Dockerfile after Right-click > Add > Add Docker Support. (this also where the .csproj file is)
Dragged the Dockerfile up one level to \Users\robk\git\Play-With-Containers then it worked.
I'm trying to publish a small .NET Core 3.1 Web App on Azure App Service (Linux), and the app won't start.
No matter if I'm publishing using Visual Studio, or Azure DevOps, i'm getting the following error on my Linux Azure App Service (which, by the way, already contains two other apps):
2021-06-23T22:19:47.102376527Z _____
2021-06-23T22:19:47.102415627Z / _ \ __________ _________ ____
2021-06-23T22:19:47.102422327Z / /_\ \___ / | \_ __ \_/ __ \
2021-06-23T22:19:47.102426627Z / | \/ /| | /| | \/\ ___/
2021-06-23T22:19:47.102430627Z \____|__ /_____ \____/ |__| \___ >
2021-06-23T22:19:47.102434927Z \/ \/ \/
2021-06-23T22:19:47.102438927Z A P P S E R V I C E O N L I N U X
2021-06-23T22:19:47.102442827Z
2021-06-23T22:19:47.102446327Z Documentation: http://aka.ms/webapp-linux
2021-06-23T22:19:47.102449927Z Dotnet quickstart: https://aka.ms/dotnet-qs
2021-06-23T22:19:47.102453427Z ASP .NETCore Version: 3.1.13
2021-06-23T22:19:47.102457227Z Note: Any data outside '/home' is not persisted
2021-06-23T22:19:47.307988432Z Running oryx create-script -appPath /home/site/wwwroot -output /opt/startup/startup.sh -defaultAppFilePath /defaulthome/hostingstart/hostingstart.dll -bindPort 8080 -userStartupCommand 'dotnet WebApplication1.dll'
2021-06-23T22:19:47.378242802Z Cound not find build manifest file at '/home/site/wwwroot/oryx-manifest.toml'
2021-06-23T22:19:47.382799606Z Could not find operation ID in manifest. Generating an operation id...
2021-06-23T22:19:47.382816206Z Build Operation ID: 7f48597c-0791-46e5-bffd-b0007d8b27b7
2021-06-23T22:19:49.335414280Z Writing output script to '/opt/startup/startup.sh'
2021-06-23T22:19:49.567879341Z Running user provided startup command...
2021-06-23T22:19:49.610748271Z A compatible installed .NET Core SDK for global.json version [3.1.409] from [/home/site/wwwroot/global.json] was not found
2021-06-23T22:19:49.610783071Z Install the [3.1.409] .NET Core SDK or update [/home/site/wwwroot/global.json] with an installed .NET Core SDK:
2021-06-23T22:19:49.610825071Z It was not possible to find any installed .NET Core SDKs
2021-06-23T22:19:49.610829471Z Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
2021-06-23T22:19:49.610835971Z https://aka.ms/dotnet-download
2021-06-23T22:19:50.944Z ERROR - Container procoding-me_0_8935305e for site procoding-me has exited, failing site start
2021-06-23T22:19:50.961Z ERROR - Container procoding-me_0_8935305e didn't respond to HTTP pings on port: 8080, failing site start. See container logs for debugging.
2021-06-23T22:19:50.978Z INFO - Stopping site procoding-me because it failed during startup.```
I've tried to create the web app on azure again, and even tried to publish the same code of the other apps, and the same problem occurs.
Anybody has a hint of the cause of this problem?
So, after a long day of trying to figure this thing out I managed to publish and app to an app service running linux. I'm using an App Service Plan (Linux, B1) that lives in a "shared" resource group since I want to run multiple apps on it. I'm also deploying the infrastructure using Bicep and the pipeline is yaml.
The issue was, as it seems, that when I was deploying the app through Azure DevOps, it was nesting the app archive in another zip-file. The app zip-file needs to be the root-folder in the app, not obvious unless you download the files that are being executed in the app service itself.
Yeah, also I'm using the self-contained version of deployment here. You can read more about it here. I had no success doing it with the framework-dependent way unless I published the app from Visual Studio 2022.
So, in the end, here are the snippets that made the thing work for me:
azure-pipelines.yaml - Build stage
- task: DotNetCoreCLI#2
inputs:
command: 'publish'
projects: '**/*Api.csproj'
arguments: '--configuration $(buildConfiguration) -r linux-x64 --self-contained true --output $(Build.ArtifactStagingDirectory)'
modifyOutputPath: false
publishWebProjects: false
zipAfterPublish: true
displayName: 'Dotnet Publish'
- task: PublishBuildArtifacts#1
inputs:
targetPath: '$(Build.ArtifactStagingDirectory)'
ArtifactName: drop
azure-pipelines.yaml - Deploy stage
- task: AzureRmWebAppDeployment#4
inputs:
azureSubscription: '$(azureSubscription)'
appType: webAppLinux
WebAppName: '$(output_appServiceName)'
packageForLinux: '$(Pipeline.Workspace)/**/a.zip' #Since we are not specifying the folder name in the steps prior, the folder will be called just a.zip, this is fine since the deployment is going to rename it any way in the app service file system anyway(in Kudu)
The app service resource in Bicep
resource appService 'Microsoft.Web/sites#2021-01-01' = {
name: '${serviceName}-${environment}-app'
location: resourceGroup().location
kind: 'app'
properties: {
serverFarmId: planId
siteConfig: {
alwaysOn: true
http20Enabled: true
linuxFxVersion: 'DOTNETCORE|5.0'
appSettings: [
{
name: 'WEBSITE_RUN_FROM_PACKAGE'
value: '1'
}
]
}
}
}
Hope this helps.
P.S. Having "corrupted" zip-files in the app service (Kudu) can cause the app to fail. I suggest anyone having this issue to either delete all files from wwwroot or simply delete the app service resource and deploy it from scratch to make sure it can start properly.
I am running C# in latest version of VS 2019 (Pro) on latest Windows 10 (Pro)
I converted my project (using MS Assistant) from Net Framework to Net 5.0.
All works well -> until I containerize.
Pre-containerization: My process architecture:
Logger TseLogger
Search engine shard 1 of 2 (TseShard -shardId 0)
Search engine shard 2 of 2 (TseShard -shardId 1)
Note that the 'shard' code is the identical code. The distinction is the 'shardId' run-time parameter.
In my solution I want to start 1 logger and 2 shards.
I could not figure out how to tell VS to start 2 copies of the same project (each with its own runtime parameters) so (as a kludge so I could test it) I cloned the TseShard project into 'TseShard 2' project and added it to the list of projects to start.
I could now set breakpoints anywhere in the code and debug (single-step as needed).
I am happy as a pig-in-you-know-what.
Next step was to containerize the projects.
So I want to generate 2 images
Logger (TseLogger)
Search engine shard (TseShard)
And, from the images, generate 3 containers: 1 logger and 2 shards.
I added Orchestration (docker-compose) support to my solution and Docker support to my TseLogger and TseShard projects.
I edited the auto-generate (by VS 2019) docker-compose.yml file:
version: '3.4'
services:
tselogger:
image: ${DOCKER_REGISTRY-}tselogger-2-3-0-6
build:
context: .
dockerfile: TseLogger/Dockerfile
tseshard0:
image: ${DOCKER_REGISTRY-}tseshard0-2-3-0-6
build:
context: .
dockerfile: TseShard/Dockerfile
ports: [52949]
volumes:
- d:/MyData:/MyData
command: -shardId 0
tseshard1:
image: ${DOCKER_REGISTRY-}tseshard1-2-3-0-6
build:
context: .
dockerfile: TseShard/Dockerfile
ports: [52950]
volumes:
- d:/MyData:/MyData
command: -shardId 1
Note that I added the suffix '-2-3-0-6' (code assembly version) to the images.
Note also that I named the shard services as 'tseshard0' and 'tseshard1'
My expectation is that it allows me to keep images of different code versions so Production can run a stable release while Dev will run new (test) releases.
My expectation is that I can reuse the same docker image (based on docker build of TseShard/Dockerfile) for both shards.
Anyway, it builds (seemingly correct).
For all its worth, the auto-generated (by VS) TseShard/Docker file (I did not edit this one):
#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/runtime:5.0 AS base
WORKDIR /app
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY ["TseShard/TseShard.csproj", "TseShard/"]
COPY ["Utils/Utils.csproj", "Utils/"]
COPY ["BinarySerialization/BinarySerialization.csproj", "BinarySerialization/"]
COPY ["Interfaces/Interfaces.csproj", "Interfaces/"]
COPY ["JsonCompare/JsonCompare.csproj", "JsonCompare/"]
COPY ["Networking/Networking.csproj", "Networking/"]
COPY ["FilterScoring/FilterScoring.csproj", "FilterScoring/"]
COPY ["DataAccess/DataAccess.csproj", "DataAccess/"]
COPY ["TseClient/TseClient.csproj", "TseClient/"]
RUN dotnet restore "TseShard/TseShard.csproj"
COPY . .
WORKDIR "/src/TseShard"
RUN dotnet build "TseShard.csproj" -c Debug -o /app/build
FROM build AS publish
RUN dotnet publish "TseShard.csproj" -c Debug -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "TseShard.dll"]
I set breakpoints at 'Main' for the logger and the shard code C# modules.
Finally, I start the docker-compose project.
It builds properly (so it seems).
Issue #1: I get an error message box from VS saying: Can not find the container with the name starting with 'TseShard' (see image below)
Issue #2: I'm not sure why it is looking for a container named 'TseShard' (which is the project name, not the image name, and not the service name).
Issue #3: The Output window from Container Tools shows:
========== Debugging ==========
docker ps --filter "status=running" --filter "label=com.docker.compose.service" --filter "name=^/TseShard$" --format {{.ID}} -n 1
========== Debugging ==========
docker ps --filter "status=running" --filter "label=com.docker.compose.service" --filter "name=^/TseShard$" --format {{.ID}} -n 1
Clearly the 'docker ps' is filtering on "name=^/TseShard$" which is looking for exactly 'TseShard'.
But I only defined services for TseShard0 and TseShard1.
See attached images.
Docker shows that the Logger is still running, and the two shards exited.
For sure, I did not reach a breakpoint (at the literal start of 'Main').
I would appreciate any help in setting up the debugging correctly so that I could set break points.
I am ultimately planning to get this to work on Linux 2 on AWS.
Many thanks in advance.
My aim is to be able to use any packer for C# applications and libraries (preferring WPF) via command line or full build-in at Visual Studio.
I came accross .NetZ (http://madebits.com/netz/) that is pretty neat and worked pretty well until I tested it with a WPF application:
PackageExample.Program -> C:\Users\[username]\Documents\Visual Studio
2012\Projects\PackageExample\PackageExample.Program\bin\Debug\PackageExample.Program.exe
COMMAND: packcompress\netz-bin-40\netz.exe -o PackageExample.Program\bin\Debug\Packed -pl
anycpu -s -z PackageExample.Program\bin\Debug\PackageExample.Program.exe
"PackageExample.Program\bin\Debug\*.dll" -d:# -v
__________________________________________
| |
| .NETZ - .NET Executables Compressor |
| Copyright (C) 2004-2013 Vasian Cepa |
| [v0.4.8] http://madebits.com |
|__________________________________________|
PE subsystem : GUI
.NET Runtime : 4.0.30319.18052
Output directory: C:\Users\[username]\Documents\Visual Studio
2012\Projects\PackageExample\PackageExample.Program\bin\Debug\Packed
RID: zip.dll
Added : C:\Users\[username]\Documents\Visual Studio
2012\Projects\PackageExample\packcompress\netz-bin-40\zip.dll [65536 byte(s) ~ 64KB]
Processing : 3 file(s)
1| C:\Users\[username]\Documents\Visual Studio
2012\Projects\PackageExample\PackageExample.Program\bin\Debug\PackageExample.Program.exe
[255488 byte(s) ~ 249KB] -> [130850 byte(s) ~ 127KB] - 49%
RID: A6C24BF5-3690-4982-887E-11E1B159B249
2| C:\Users\[username]\Documents\Visual Studio
2012\Projects\PackageExample\PackageExample.Program\bin\Debug\PackageExample.Lib1.dll
[4096 byte(s) ~ 4KB] -> [1577 byte(s) ~ 1KB] - 62%
RID: PackageExample.Lib1!2!1Version=1.0.0.0!2!1!4=neutral!2!1PublicKeyToken=null
3| C:\Users\[username]\Documents\Visual Studio
2012\Projects\PackageExample\PackageExample.Program\bin\Debug\PackageExample.Lib2.dll
[4608 byte(s) ~ 4KB] -> [1617 byte(s) ~ 1KB] - 65%
RID: PackageExample.Lib2!2!1Version=1.0.0.0!2!1!4=neutral!2!1PublicKeyToken=null
Done [00:00:00.300]
The packed app throws this: http://i.imagebanana.com/img/251ygj82/Unbenannt.PNG
(The ressource mainwindow.xaml cannot be found.)
The problem seems to be the xaml .NetZ confuses, but I found some people who got it working on the internet, but I do not get any problem solution.
Are you able to help me in this case?
Additional information: It might be interesting to mention I even tried this with the .NET 2.0 .NetZ build on a .NET 3.5 WPF application.
I also had problems using NetZ to compress an WPF 4.0 exe and DLLs into a single exe.
My app.xml.cs would start to run, but then an UnhandledException of type NotImplementedException would be thrown:
Baml2006SchemaContext.ResolveBamlType ...
To troubleshoot this, I ran fuslogvw.exe to see assembly binding errors, and discovered that GalaSoft.MvvmLight.Wpf4.dll was failing to load from the Netz-packed assembly.
I then switched to NetZ.exe compiled from source and tried again.
After repeated experimentation, I see that if I recompile and NetZ-pack the app, it sometimes starts working. Recompile again the main app again, and NetZ produces a failing app.
In other words, something is intermittent.
Sorry for the not-so good news - either try another packing scheme, or try NetZ repeatedly on many builds, until you find a working one.