I have Asp.net core Xunit integration tests that connect to MongoDb to test basic repositories on collections. The tests are built and run in a container in AKS. I have setup the test fixture to connect Azure Key Vault to retrieve connection string to a MongoDb.
var pathToSetting= Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
var configuration = new ConfigurationBuilder()
.SetBasePath(pathToSetting)
.AddJsonFile("appsettings.json")
.AddEnvironmentVariables();
var secretClient = new SecretClient(
new Uri("url_to_Azure_keyVault"),
new DefaultAzureCredential(),
new SecretClientOptions()
{
Retry =
{
Delay = TimeSpan.FromSeconds(2),
MaxDelay = TimeSpan.FromSeconds(4),
MaxRetries = 2,
Mode = RetryMode.Exponential
}
});
configuration.AddAzureKeyVault(secretClient, new KeyVaultSecretManager());
I am using the following Docker file for the integration tests:
#Grab an OS image made to run the .Net Core SDK
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
#copy files for build
WORKDIR /testProject
COPY . .
RUN dotnet build tests/integrationTest.csproj --output /testProject/artifacts
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS final
COPY --from=build ["/testProject/artifacts", "/testProject/artifacts"]
ENTRYPOINT dotnet test /testProject/artifacts/integrationTest.dll
The tests run fine locally from Visual Studio but fail with exception below when run in container both locally and in AKS.
[xUnit.net 00:00:03.10] IntegrationTest1 [FAIL]X
Test1 [1ms]
Error Message:
System.AggregateException : One or more errors occurred. (SharedTokenCacheCredential authentication failed: Persistence check failed. Inspect inner exception for details) (The following constructor parameters did not have matching fixture data: TestFixture testFixture)
---- Azure.Identity.AuthenticationFailedException : SharedTokenCacheCredential authentication failed: Persistence check failed. Inspect inner exception for details
-------- Microsoft.Identity.Client.Extensions.Msal.MsalCachePersistenceException : Persistence check failed. Inspect inner exception for details
------------ System.DllNotFoundException : Unable to load shared library 'libsecret-1.so.0' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment
variable: liblibsecret-1.so.0: cannot open shared object file: No such file or directory
Any ideas how to troubleshoot this error ?
I came across this potential fix while working on my own issue:
Wherever you create new DefaultAzureCredentialOptions, you should also set the property ExcludeSharedTokenCacheCredential to true.
In your WSL environment install libsecret-1-dev. In Ubuntu for example, run the command sudo apt install libsecret-1-dev. This will add libsecret-1.so.0 to your system so that MSAL can find it.
https://hungyi.net/posts/wsl2-msal-extensions/
It didn't work for me, but I am using a docker container that doesn't have full access to apt. I can't install libsecret-1-dev.
Not a root cause, but same error popped up for me this morning. Rolling Microsoft.Web.Identity package down from 1.7.0 to 1.6.0 did the trick.
Looks like from the GitHub issues on other Azure packages, wrapping these exceptions is a common bug that gets logged.
Switching Azure.Identity 1.2.3 to 1.2.2 did the trick for me (this page helped me https://hungyi.net/posts/wsl2-msal-extensions/).
Related
Running into a total dead-end here.
I've created a Publish Profile for a .net6 application that we want to publish to IIS with Web Deploy. In the Entity Framework Migration section, the option to "Apply this migration on publish" is selected.
When manually clicking publish, everything works. However, we want to automate this in TeamCity using the .NET build runner. The publish step fails at:
Generating Entity Framework SQL Scripts...
Executing command: dotnet ef migrations script --no-build --idempotent --configuration Release --output "C:\TeamCity\buildAgent\work\cbf95cc2b4413601\MySolution.Api\obj\Release\net6.0\PubTmp\EFSQLScripts\MySolution.Data.MyContext.sql" --context MySolution.Data.MyContext
C:\Program Files\dotnet\sdk\6.0.400\Sdks\Microsoft.NET.Sdk.Publish\targets\TransformTargets\Microsoft.NET.Sdk.Publish.TransformFiles.targets(221,5): error : Entity Framework SQL Script generation failed
Internal error message details: BuildMessage1 0 Text DefaultMessage ERROR 400682522803500 tags:'tc:parseServiceMessagesInside'
Error message is logged
Build FAILED.
I cannot find any specific error messages anywhere in any log. Looking in the Microsoft.NET.Sdk.Publish.TransformFiles.targets file shows that it's failing on GenerateEFSQLScripts - an MSBuild command that executes dotnet ef under the covers.
I thought this might be a case of dotnet ef not being installed on the build agent. But when I manually run the command myself from C:\TeamCity\buildAgent\work\cbf95cc2b4413601\MySolution.Api, it succeeds, and the SQL scripts are successfully created.
I also thought it might just be a case of the command being run in the wrong directory (i.e. in the root MySolution folder rather than the MySolution.Api folder), but explicitly setting the working directly fails at the same point, with the same error.
Has anyone seen this before? Or could point me to where an actual error might be located?
I'm trying to start a headless chrome with a puppeteer in Azure Functions on Linux.
What do I do? I have a “Function App” that looks this way:
And I have a function:
I build this function remotely this way:
func azure functionapp publish {appname} --build remote
And this is what I get when I try to run a function:
Result: Failure
Exception: Failed to launch the browser process!
/home/site/wwwroot/node_modules/puppeteer/.local-chromium/linux-1011831/chrome-linux/chrome: error while loading shared libraries: libgobject-2.0.so.0: cannot open shared object file: No such file or directory
I've seen this topic already (Puppeteer throws launch exception when deployed on azure functions node on Linux) but they recommend do a remote build, which I do and it still doesn't help.
Maybe I'm using wrong App Service Plan, but I checked and there were nothing related to special linux setup there.
The reason was that I was indeed using the wrong App Service Plan. I needed a “Function App” one. When I recreated a function with the right service plan, everything worked just fine.
I was able to deploy the azure function without the use of func azure functionapp publish {appname} --build remote. I did it using the visual studio code.
But before that I installed the puppeteer inside the function folder using
npm install puppeteer
Then I added the node_modules name in the .funcignore file.
Then I added the following setting in setting.json in the .vscode folder
"azureFunctions.scmDoBuildDuringDeployment": true
Then deploy the function normally through vscode
Question - Is there a better/right way to get the application's launch path?
Setup -
I have a console application that runs in a Linux Debian docker image. I am building the application using the --runtime linux-x64 command line switch and have all the runtime identifiers set appropriately. I was expecting the application to behave the same whether launching it by calling dotnet MyApplication.dll or ./MyApplication but they are not.
Culprit Code -
I have deployed files in a folder below the application directory that I reference so I do the following to get what I consider my launch path. I have read various articles saying this is the correct way to get what I want, and it works depending on how I launch it.
using var processModule = Process.GetCurrentProcess().MainModule;
var basePath = Path.GetDirectoryName(processModule?.FileName);
When launching this using the comand dotnet MyApplication.dll the above codes path is /usr/share/dotnet
When launching this using the command ./MyApplication.dll the path is then /app
I understand why using dotnet would be different as it is the process that is running my code, but again it was unexpected.
Any help here to what I should use given the current environment would be appreciated. Ultimately I need the path where the console application started from as gathered by the application when it starts up.
Thanks for your help.
This code should work:
public static IConfiguration LoadConfiguration()
{
var assemblyDirectory = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
.....
}
I have a .NET Core repo in VSTS. I'm trying to create a Build pipeline that builds a Docker image and adds it to my Azure Container Registry. My Build pipeline has a Docker task. This task has the "Build an image" action selected. This action relies on my Dockerfile, which looks like this:
FROM microsoft/dotnet:2.1.2-runtime-nanoserver-1803
# Install .NET Core
ENV DOTNET_VERSION 2.1.2
When my Build pipeline runs, I get an error that says:
failed to register layer: re-exec error: exit status 1: output: ProcessUtilityVMImage \\?\C:\ProgramData\docker\windowsfilter\82aba535faccd8bf0e5ce3c122247672fa671214000a12c5481972212c5e2ca0\UtilityVM: The system cannot find the path specified.
##[error]C:\Program Files\Docker\docker.exe failed with return code: 1
Why am I getting this error? How do I fix it?
It should be the same issue with this one : https://github.com/Microsoft/vsts-tasks/issues/6510
Seems it still have some issues with nanoserver-1803
Just try to setup and host a custom agent on Azure VM, then check it again.
https://github.com/Microsoft/vsts-tasks/issues/6510#issuecomment-370152300
I found maybe an explication about this error: VSTS agents seem not
support nanoserver-1709 actually. Maybe this will change with the next
version 1803.
See details here: Microsoft/vsts-agent#1393
When I setup and host a custom agent on a machine on Azure, it's
working. So it's not a bug with this task. I close this issue. Thanks!
I followed this article to setup a performant ASP.NET Core deployment using Docker. This works until I try to start the container using docker run which calls dotnet MyAppName.dll There I got an exception, that the View path is not existing:
Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentException: The directory name /app/Views/ is invalid.
And thats true, cause in the folder created by dotnet publish area only dll files and no View folder:
user#server:/etc/jenkins/workspace/App# ll publish-output | grep View
-rwxr--r-- 1 root root 237K Aug 31 19:26 Microsoft.AspNetCore.Mvc.ViewFeatures.dll
I cant understand this, cause the View folder is included in the publishOptions like wwwroot too, which is also missing:
"publishOptions": {
"include": [
"wwwroot",
"Views/**/*.cshtml",
"Areas/**/*.cshtml"
]
},
I also tried "Views" instead of "Views/**/*.cshtml" but not working. In my understanding, those publishOptions should result in copying those folders to the publishing-directory when using dotnet publish.
What am I doing wrong?
I'm using the microsoft/aspnetcore-build:1.0.1 image for building and microsoft/aspnetcore:1.0.1 for starting the app like recommended as best practice in the article.
UPDATE
Seems to be a problem on linux only. My Win10 development machine works fine, there I get any view-folders published from the main app and areas as expected.
UPDATE #2 Using the examples on the aspnetcore-build repo on the docker hub, its not working too.
UPDATE #3 I created a new ASP.NET Core MVC project on my Windows 10 development machine using Visual Studio, then transferred it to the linux box: Not working, the views are missing.
UPDATE #4 Created a new app using dotnet new -t web directly on the linux box: Works like expected!
UPDATE #5 I ran dotnet new -t web on the Windows machine, moved the created folder to the linux server: Not working - Strange...
The problem was a missing space in the documentation before the dot, which should refer the current folder.
Wrong (1:1 copy from the description of the docker image)
RUN dotnet publish --output /out/. --configuration Release
Correct
RUN dotnet publish --output /out/ . --configuration Release
Here is the space missing: --output /out/{Space}.