My understanding from the Microsoft documentation is the userSecret configuration is supposed to be automatically created by the WebApplication.CreateBuilder() while in the development environment. This is not true for my current WebAPI .net7 application. I have run the init command and populated the secrets file. Any ideas on why the userSecrets would be missing from the configuration sources?
Related
Visual Studio now generates Dockerfile for dotnet projects, and we are using it (with slight tweaks) for our continuous integration.
However that Dockerfile does not have any provision for configuring nuget. It even only copies the .csproj file from context before running dotnet restore to avoid re-running that step during development.
But our project requires some modules from internal, password-protected repository, so I need to provide package sources and credentials to the dotnet restore command inside.
What is the best current practice for injecting a (environment-specific) nuget configuration?
This is documented here: https://github.com/dotnet/dotnet-docker/blob/main/documentation/scenarios/nuget-credentials.md.
To summarize, there are a variety of ways in which this can be done:
Use a multi-stage build to protect nuget.config that contains hard-coded credentials. Only recommended if you ensure that credentials are kept out of source code control and the nuget.config file is ephemeral.
Passing secrets by file with BuildKit. This is similar to the previous option but makes use of Dockerfile secrets to provide access to the nuget.config file.
Use environment variables in nuget.config. In this scenario, the nuget.config file would reference environment variables for its credential values. The environment variables would then be set by the build machine when executing a docker build.
Use the Azure Artifact Credential Provider. This is only possible if you make use of Azure Artifacts for your package feed.
No matter which option you choose, be sure that credentials are never stored within an image layer that is published.
I'm pulling my hair out. I've got an On Prem installation of Azure DevOps, and a pair of build agents. We're trying to move to .net core, but we have never been able to get it to work to push the nuget packages into DevOps feed. This should be straight forward.
The whole environment is hidden behind corporate firewall and proxy, and while the proxy config is good for nuget pull, and any other activity you care to name, we cannot invoke nuget push (or dotnet push) to our internal package repository. The only error I get is a 502 (bad gateway) from tunnel.js, but I've explicitly set the address of the DevOps server in NO_PROXY (environment variables, .proxy & .proxybypass for the devops agent, netsh winhttp proxy, build agent user internet connection settings, and %AppData%\Nuget\Nuget.Config file). Git works, nuget restore works, build works, packaging works, but the dotnet push (or nuget push) fail with this error.
Can anyone suggest any other places I might need to set a proxy bypass or no_proxy setting?
There can be many reasons why you are getting this problem, which may be related to your organization network, users roles and permissions or even task may be restricted by any policy.
But if above mentioned things are not true in your case then you should configure NuGet tools to authenticate with Azure Artifacts and other NuGet repositories. If all of the Azure Artifacts feeds you use are in the same organization as your pipeline, you can use the NuGetAuthenticate task without specifying any inputs. Check this Restore and push NuGet packages within your organization document for more information.
This task must run before you use a NuGet tool to restore or push packages to an authenticated package source such as Azure Artifacts. This task installs the Azure Artifacts Credential Provider into the NuGet plugins directory if it is not already installed.
If your agent is behind a web proxy, the NuGetAuthenticate will not set up nuget.exe, dotnet, and MSBuild to use the proxy. Then set the environment variable http_proxy and optionally no_proxy to your proxy settings as shown below.
nuget.exe config -set http_proxy=http://my.proxy.address:port
nuget.exe config -set http_proxy.user=mydomain\myUserName
Check this NuGet CLI environment variables for more information.
I am trying to run a dotnetcore Console application in a ServiceFabric GuestExecutable Container. While I was adding this GuestExecutable service to my SF application, I cofigured as follows
Code Package Folder -> ..repos\NewDllGuestSF\CoreConsole\bin\Debug\netcoreapp2.0
Program -> CoreConsole.dll
Working Folder -> CodePackage
Here, I know I am trying to host this .dll file as my executable for the GuestExecutable service. This is what I am trying to do but could not somehow. When I tried the same with the treditional .NetFramework app and with an .exe executable, I am able to run it successfully on SF cluster. But I need to do is with dotnetcore application and of course with a dll executable.
So far I have tried is -
I can generate a dll as well as an exe while building my dotnetcore console application and use the generated .exe file in GuestExecutable. But here, I have to configure my console app to target multiple Frameworks as "netcoreapp2.0;net461", that is something I can not do for some reasons.
When I run my dotnetcore Console app with a dll executable in SF cluster, I faced the following error
Here if we see, the GuestExecutable service remains in healthy state but the application doesn't.
Can anyone please help me out on this, all I want to do is to host a .dll file as entry point in a GuestExecutable SF service.
As far as I understand you need to configure CodePackage in ServiceManifest.xml to run your .dll using external executable.
Here is the example how this could be done (please pay attention to IsExternalExecutable="true" attribute):
<CodePackage Name="Code" Version="1.0.0">
<EntryPoint>
<ExeHost IsExternalExecutable="true">
<!-- We are using dotnet cli to launch our Service.dll -->
<Program>dotnet</Program>
<Arguments>Service.dll</Arguments>
<WorkingFolder>CodePackage</WorkingFolder>
</ExeHost>
</EntryPoint>
</CodePackage>
Hope it helps.
My .NET Core application is using Config Server which is referencing the configuration values which are stored in .yml at Git repo.
Do we need to restart the application once the configuration value updated in Git to get the value to be reflected?
I wanted to understand is this the expected scenario or am I missing something else?
Yes, this is how it works by default. You can configure whether the cofiguration will be fetched from git, or from the cloned config in the config-server's memory with the 'refreshRate' configuration.
See documentation for more informationt:
https://docs.pivotal.io/spring-cloud-services/2-0/common/config-server/configuring-with-git.html
I'm using biztalk 2009 and trying to deploy via vs.net 2008.
My project is just an empty BizTalk application with an empty orchestration. I've created a strong name key file and selected it in the Project properties under "Signing". I've also specified an application name.
When I deploy I get the error:
Error 1 Failed while Updating the Application 'BizTalk.System'. Permission denied. The current user does not have privilege to complete the operation. 0 0
Any ideas on what this means and what I'm doing wrong? From what I know it's not supposed to be updating BizTalk.System at all.
The BizTalk.System application is read-only so it can't be updated, but I doubt that you would be trying to update it without knowing it, especially with such a simple sounding project. Your new application should be referencing BizTalk.System though... maybe there is a problem creating this dependency?
These are some of the initial steps I would take to troubleshoot:
Check the BizTalkMgmtDb database to make sure you have the appropriate permissions
Check the EventViewer logs for more details about the Access Denied error
Try creating an empty application manually in the BizTalk Admin Console, see if you get the same error
If you can create the application manually, try deploying the project via VS 2008 to the empty application and see if you get the same error
Hopefully one of these will help pinpoint what the problem is (or even better, hopefully you've alreadty resolved the issue :) )
I agree that you shouldn't be deploying to the BizTalk.System application.
To check that you are deploying to the correct place, open your BizTalk project properties and click on the 'Deployment' tab (I'm making the assumption above that you are deploying locally, in which case the BizTalk Group Server and Configuration Database should already be set).
Under BizTalk Group, set Application Name to 'Test Application' (this can be changed later to something more meaningful); ensure all of the other boolean properties on the Deployment tab are set to true, with the exception of the Enable Unit Testing property.
When you now deploy the project from Visual Studio (by right clicking the project name and selecting 'Deploy', the new BizTalk Application will be created and the project deployed as a resource to that Application. Watch the VS Output window to check that they deployment is successful.
Once the deployment has completed, open the BizTalk Server Administration Console and expand the Applications node, you should now see a new application called 'Test Application'. If you expand the new app and take a look in Resources, you will see your recently deployed project.