The last container I build on Azure DevOps was with version 2.1.300 of the SDK. After upgrading to .Net Core 2.2 with SDK 2.2.203 I get the error below.
/usr/share/dotnet/sdk/NuGetFallbackFolder/microsoft.aspnetcore.razor.design/2.2.0/build/netstandard2.0/Microsoft.AspNetCore.Razor.Design.CodeGeneration.targets(131,5):
error : rzc generate exited with code 1.
The container still builds successful on my local machine. I tried the suggestion in this post but with the same result. I even went back to version 2.1, but now with the same problem. Any idea what can cause this problem?
Update 09-05-2019
I've created a self hosted agent. It has te same problem, but when I build the docker image myself on the same machine (self hosted agent) the build is successful. I'm out of ideas.
I figured it out. I had multiple views within a components folder. This caused the problem for me. Hope it helps someone.
Related
On our new company laptops we are running into issues running containers in docker desktop from visual studio. We tried a bunch of things which were unsuccessful. Any help / thoughts would be great as we are running out of ideas.
.Net Core Version 6 / Asp.net Core (web api)
Running docker compose manually in cmd works and I'm able to hit the site.
Running docker compose debug profile from visual studio results in:
The output window shows "The program '' has exited with code 4294967295 (0xffffffff)."
Docker desktop shows the container running but I can't grab logs from it or hit it in the url.
WSL is fine and everything is working there.
My home machine works great and i'm able to launch and debug containers.
Faced with identical error, I was able to resolve by deleting VSDBG debugger folder:
%USERPROFILE%\vsdbg\vs2017u5
After deleting the folder start Visual Studio debugger (F5) and as a result VSDBG debugger will be recreated
Container Tools build properties https://learn.microsoft.com/en-us/visualstudio/containers/container-msbuild-properties?view=vs-2022
I have the same error when I'm trying to start 2 project simultaneously. And one project was cloned from another. So, they have the same GUIDs of projects in .sln files. After changing GUIDs all works ok.
Most of the time this error code does not provide any concrete information. In my case I had to go and find error details in logs folder. Log file is generally located at 'YourProject\bin\Debug\App_Data\Logs' location.
There was an issue with 3rd party service and it worked after fixing the service issue.
I'm running the Jenkins as a Docker container on a Virtual Machine on Google Cloud Platform. On the very first screen of setup, I can see that a lot of plugins did not install in my Jenkins server?
Please let me know how to resolve this issue? Is it something due to with the security on the cloud by default which restricts downloading of plugins?
Refer following link for screenshot:-
https://storage.googleapis.com/mydockerissues/Jenkins%20Plugins%20Issue.PNG
Cheers
Something similar happened to me when running Jenkins on Docker on my local machine. To get everything to install I had to keep retrying. It took several retries but eventually I got everything installed.
I'm not sure why this is the case. Maybe it fails downloads whose dependencies aren't installed yet?
I'm currently trying to use IntelliJ to deploy to a local GlassFish instance running in Docker on my Windows 10 box.
I'm following the instructions here on deployment, using the remote server setup.
However, when calling the run command, I get the following error from IntelliJ:
Artifact my-project:war: java.io.IOException: com.sun.enterprise.admin.remote.RemoteFailureException: File not found : /opt/glassfish4/glassfish/domains/my-domain/config/C:[PATH_TO_MY_TARGET_DIR]\my-project.war
It seems like it's trying to pass too much of the path when uploading.
Interestingly, I tried this same setup (different IP addy) deploying to a GlassFish instance running in Docker in a local Ubuntu VM, and it has no problem.
Anyone gone down this road?
I have the same problem and contacted JetBrains.
It seems to be a bug in IntelliJ wich will be hopefully fixed quite soon. Here is the link for reference https://youtrack.jetbrains.com/issue/IDEA-180292.
I created a new .NET Core Console Application with Visual Studio 2017 (RTM). Then added Docker support and got the docker file + compose files just fine. However there are few issues with them.
Docker compose files have version 2 which makes the build fail to the following error message
Microsoft.DotNet.Docker.CommandLineClientException: client version 1.22 is too old. Minimum supported API version is 1.24, please upgrade your client to a newer version.
This can be fixed by manually changing the compose file versions to 2.1. (not sure if valid fix) Then you'll get another error message
MSB4006 There is a circular dependency in the target dependency graph involving target "DockerCleanServiceReferences".
This I have no idea how to fix. I know the error message is due to some configuration that causes circular reference (e.g. post build event that does build)
So, any resources or tips how to package the .NET Core console application into docker container manually? I'm just getting to know Docker so don't assume I know anything of it yet.
Another question, that is there some place where I could get updated versions of these Visual Studio templates or are these known issues?
It turned out the problem for me was having my DockerFile, SLN file, and CSPROJ file all in the same folder. You know how when you create a solution, it asks you if you want to create a subdirectory? If you do not, and your SLN and CSPROJ files share the same folder, inevitably the Docker files will be added to this same folder, creating the circular reference. If your SLN file lives in the directory above your CSPROJ file, the DockerFile et al will be put into your parent directory with the SLN file, and all will be well. This solved it for me.
Can you please check if your Docker for Windows is targeting Linux? It's likely you were targeting Windows container, which is not supported with .NET Core yet.
On my first spin of VS2017 with docker, using the default template, I ran in to the same issue.
I referred to this article - https://blogs.msdn.microsoft.com/containerstuff/2017/03/13/visual-studio-2017-client-version-1-22-is-too-old/
This is what worked for me - As recommended, made this changes in docker-compose project's docker-compose.ci.build.yml :
The 'version' parameter on the top of the file which was set to 2, was change to 2.1
Repeated the same changes on the other files in the project including:
docker-compose.yml
docker-compose.override.yml
docker-compose.vs.debug.yml
docker-compose.vs.release.yml
Regarding your question on how to package a .NET Core console application into a Docker image manually. The https://github.com/dotnet/dotnet-docker-samples are intended to answer that very question. Check them out. If you run into issues with them or have suggestions please log an issue (https://github.com/dotnet/dotnet-docker-samples/issues).
Thanks for the post. We will be adding Nano Server container tooling "soon". Until then, you can work with Linux containers which will give a similar experience.
I have been trying for sometime to get the TFS plugin working, and have had "semi" success.
The parts of the process that use Team Explorer command line client work well (I have defined the TFSPROXY environment variable, which seems to work.)
As soon as the plugin gets to the piece that uses the SDK, I get a stack trace printed, with the main error:
com.microsoft.tfs.core.exceptions.TECoreException: Unknown host somehost.on.corporate.network.
I have tried using the environment variables: HTTP_PROXY, and TFSPROXY. I have also tried adding the registry keys at HKLM/Software/MS/VisualStudio/10.0/TeamFoundation/SourceControl/Proxy (also added v9.0).
My question is: Is there any way to configure proxy settings for the SDK that the plugin is using, or has someone else had success with another alternative?
For anyone else who may be having this issue, I found that it is only the latest versions of the plugin using the SDK (3.0+), and the previous versions (2.0 and less) are using only the command line tool.
So as a workaround, I have downgraded to 2.0 and everything seems to be working correctly now.