I installed dotent core on Ubuntu v16.04. Problem is when I try to use dotnet user-secrets it says:
No executable found matching command "dotnet-user-secrets"
dotnet core version:
1.0.0-preview2-003131
dotnet screenshot:
To use the Secret Manager in .NET Core, you will have to install it to the project:
Add the line Microsoft.Extensions.SecretManager.Tools to the tools section of your project.json
Run dotnet restore
You can find more information about it in the official .NET documentation.
When I added that package through nuget it added it to the "dependencies" section. So I had to move the line below:
"Microsoft.Extensions.SecretManager.Tools": "1.1.0-preview4-final"
out of the "dependencies" section and into the "tools" section in the project.json file. Then I ran dotnet restore and then it worked. Just make sure you run those commands on the same directory where project.json file is located.
Related
This is pretty easy to replicate but also code here:
https://github.com/dominicshaw/dotnet-publish-error
create an empty wpf project using .NET7
create a publish profile for ClickOnce
publish via command line (not visual studio)
Publish profile is almost totally standard (view here)
Command line from project directory:
dotnet publish PublishError.csproj -p:PublishProfile=ClickOnceProfile
Subsequent error:
MSBuild version 17.4.0+18d5aef85 for .NET
Determining projects to restore...
All projects are up-to-date for restore.
C:\Program Files\dotnet\sdk\7.0.100\Microsoft.Common.CurrentVersion.targets(4149,5): error MSB4062: The "Microsoft.Build.Tasks.RequiresFr
amework35SP1Assembly" task could not be loaded from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKey
Token=b03f5f7f11d50a3a. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, a
nd that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\Users\shawd\source\repos\PublishError\Publi
shError\PublishError.csproj]
I have the latest SDKs installed and VS2022 up to date. This only happens via command line - I am able to publish from Visual Studio (I am setting up devops, so require command line).
This happens regardless of adding nuget package for Microsoft.Build.Tasks.Core. Note however nuget package v15.1.0.0 is not available - I have tried 15.1.548 and the latest instead.
Totally at a loss! Any ideas very welcome.
Thanks vm
During the tests with your project and files, I finally managed to publish it successfully with the command dotnet publish PublishError.csproj -p:PublishProfile=FolderProfile.
Here is the document for dotnet publish, as is referred,
The preceding example uses the FolderProfile.pubxml file that is found
in the <project_folder>/Properties/PublishProfiles folder. If you
specify a path and file extension when setting the PublishProfile
property, they are ignored. MSBuild by default looks in the
Properties/PublishProfiles folder and assumes the pubxml file
extension.
And I also succeeded with dotnet publish with your project.
==============================
update on 11/19
So I suppose that the issue is resulted from your definition for -p:PublishProfile=ClickOnceProfile,it will change the path where this command would search for the publish file
A partial answer as my workaround for anyone struggling with a similar problem:
I have found it impossible to do this with the dotnet cli but I can do it with MSBuild if I specifically target 17.4 (VS2022). By default, my Azure DevOps Server 2020 capability is the 2019 MSBuild (15.X), so I have to be explicit:
"C:\Program Files\Microsoft Visual Studio\2022\Professional\Msbuild\Current\Bin\MSBuild.exe" /restore /Verbosity:m /t:Publish /p:RuntimeIdentifier=win-x64 /p:configuration=Release /p:PublishProfile=ClickOnceProfile
This works - so in my pipeline I have created a batch file which runs this, then I copy the files to my ClickOnce location.
Not ideal, but a working pipeline.
Interesting side note - this dotnet cli command which should be idenitical (and indeed uses the correct 17.4 MSBuild) - does not work (with the same error):
dotnet msbuild -target:Publish -property:RuntimeIdentifiers=win-x64;Configuration=Release;PublishProfile=ClickOnceProfile
I'm building an ASP.NET Core 2.0 Web API application that is hosted in an Ubuntu environment. So far, I've had great success getting things building and running (for the .NET Core app) in Ubuntu.
For the database, I have a SqlProj included in my solution. The project includes typical things such as tables, SPs, and pre/post deployment scripts. I'm using the following command (on my Windows-based dev machine) to build and deploy this project:
msbuild .\MyProject.DB.sqlproj /t:Build /t:Publish /P:SqlPublishProfilePath="./PublishProfiles/MyProject.DB.publish.xml"
When I take this approach, everything builds and deploys properly; however, since I will be taking advantage of the .NET Core CLI commands + CI/CD that targets an Ubuntu environment, I'd like to do something more like:
dotnet msbuild .\MyProject.DB.sqlproj /t:Build /t:Publish /P:SqlPublishProfilePath="./PublishProfiles/MyProject.DB.publish.xml"
In Windows, I immediately get the error:
error MSB4019: The imported project "C:\Program Files\dotnet\sdk\2.1.4\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Basically, what I'm asking is how to successfully build and deploy a SqlProj project in an Ubuntu environment. I've tried Googling, but I have had zero luck thus far. All of the similar issues that I've found were for individuals who were editing their .proj file to target their VS folder's SSDT. All of these individuals were fixing the issue in Windows. This approach will not work in Ubuntu, since the targets file uses Windows registry keys.
EDIT: I'm aware that SSDT is needed in order to perform such a deployment using MSBuild. I've found no evidence that installing/using SSDT is even possible in Ubuntu. If it is not, perhaps there is an alternative solution?
FYI, I'm aware that using a code-first approach with EF Core is possible. I'm attempting to take the raw SP approach (along with leveraging indexes) and keep track of all of my code using SqlProj instead. This will all be stored and CI/CDed from a Git repo.
You can use this NuGet package to deploy without installing SSDT https://www.nuget.org/packages/Microsoft.Data.Tools.Msbuild
I don't know if it will run on Ubuntu or integrate at all with the dotnet cli
My 2020 Solution
I would like to revisit this in 2020 with an updated answer to my original question.
I have taken a different approach to building an deploying SQL Server projects. My current approach is to build a pipeline that uses a vs2017-win2016 agent and use this to build a .dacpac. From there, you build a deployment pipeline to deploy the dacpac (from your artifact drop) out to the SQL Server instance.
This approach better accommodates DevOps methodologies and removes the manual process associated with my previous solution.
You can read more about this here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/apps/aspnet/build-aspnet-dacpac?view=azure-devops
I can't speak to whether or not this will work on Ubuntu, but we recently got through this on a Windows build machine that does not have SSDT installed, using the NuGet package mentioned above. The breakthrough came from piecing together the details in the article below, specifically that using the SDK with MSBuild needed to have environment variables set in order to work.
https://blogs.msdn.microsoft.com/ssdt/2016/08/22/part-5-use-your-own-build-and-deployment-agent/
With that added info, we installed the NuGet package in the root of the solution folder and then wrote a build script in PowerShell. The script sets the environment variables first and then calls MSBuild on the SqlProj file with the appropriate output directory. We don't specifically publish at that point, but instead publish the artifact to Octopus Deploy in our workflow which does the actual deployment.
Again, not sure it will help on Ubuntu, but thought the additional detail might be useful.
As an alternative, it is possible to achieve this with dotnet cli and sqlpackage as explained here using an MSBuild Sdk.
You basically have a database project. Let's call it "DatabaseProject".
You create a new project which is a .NET standard c# library that you can call "DatabaseProject.Build".
Then you can configure you DatabaseProject.Build.csproj as such:
<Project Sdk="MSBuild.Sdk.SqlProj/1.11.4">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<Configurations>Debug;Release</Configurations>
</PropertyGroup>
<ItemGroup>
<Content Include="..\DatabaseProject\**\*.sql" />
<Content Remove="..\DatabaseProject\bin\*.sql" />
<Content Remove="..\DatabaseProject\**\*.PostDeployment.sql" />
<PostDeploy Include="..\DatabaseProject\**\*.PostDeployment.sql" />
</ItemGroup>
</Project>
Be Aware The version used V1.11.4 is the one that supports the current .NET SDK shipped with visual studio at the time of the edit of this post. Check out the github repo to get the latest nuget version for your projet.
Using dotnet build will generate a dacpac that you will be able to use with either dotnet publish or sqlpackage.
You can then publish to you SqlServer instance.
If you're like me using a linux runner in your CI, you'll probably need SqlServer authentification method and then run either
sqlpackage /Action:Publish \
/SourceFile:\"DatabaseProject.Build/bin/Debug/netstandard2.0/DatabaseProject.Build.dacpac\" \
/TargetServerName:MyDatabaseServerName \
/TargetDatabaseName:MyDatabaseName \
/TargetUser:Username\
/TargetPassword:Password
or using a profile generated by visual studio :
sqlpackage /Action:Publish /Profile:\"DatabaseProject/PublishProfile/MyProfile.publish.xml\" /SourceFile:\"DatabaseProject.Build/bin/Debug/netstandard2.0/DatabaseProject.Build.dacpac\"
or
dotnet publish /p:TargetServerName=MyServerName /p:TargetDatabaseName=MyDatabseName /p:TargetUser=<username> /p:TargetPassword=<password>
Azure Data Studio now has an extension that lets you build database projects (sqlproj) using the dotnet tool. The brains behind building the project lies in the SQL Server Tools package, which is where the extension gets the required "BuildDirectory" DLL and targets dependencies.
Though not documented, if you want to set this up completely headless outside of Azure Data Studio, you can follow their CLI guide, https://learn.microsoft.com/en-us/sql/azure-data-studio/extensions/sql-database-project-extension-build-from-command-line?view=sql-server-ver15, but instead extract the necessary files from the RHEL release in https://github.com/microsoft/sqltoolsservice/releases and then follow the rest of the extension's documentation. Here is a working Dockerfile that demonstrates the approach:
FROM mcr.microsoft.com/dotnet/sdk:6.0
WORKDIR /app
RUN apt-get update \
&& apt-get install -y curl
# SSDT dlls and targets file used by Azure Data Studio Extension can be found in the SQL Tools Service project
RUN curl -sSL -o /tmp/sqltools.tar.gz https://github.com/microsoft/sqltoolsservice/releases/download/v3.0.0-release.181/Microsoft.SqlTools.ServiceLayer-rhel-x64-net6.0.tar.gz
# Extract files that are required per https://learn.microsoft.com/en-us/sql/azure-data-studio/extensions/sql-database-project-extension-build-from-command-line?view=sql-server-ver15
RUN mkdir /tmp/sqltools && tar -xzf /tmp/sqltools.tar.gz -C /tmp/sqltools && \
mkdir /app/BuildDirectory && cd /tmp/sqltools && cp \
Microsoft.Data.SqlClient.dll \
Microsoft.Data.Tools.Schema.Sql.dll \
Microsoft.Data.Tools.Schema.SqlTasks.targets \
Microsoft.Data.Tools.Schema.Tasks.Sql.dll \
Microsoft.Data.Tools.Utilities.dll \
Microsoft.SqlServer.Dac.dll \
Microsoft.SqlServer.Dac.Extensions.dll \
Microsoft.SqlServer.TransactSql.ScriptDom.dll \
Microsoft.SqlServer.Types.dll \
System.ComponentModel.Composition.dll \
System.IO.Packaging.dll \
/app/BuildDirectory && \
rm -r /tmp/sqltools
#dotnet build your-database-project.sqlproj /p:NetCoreBuild=true /p:NETCoreTargetsPath="/app/BuildDirectory"
The commented command at the end shows what you could run inside the container in the directory with your database project.
This can also then be combined with a container utilizing sqlpackage to implement a full dacpac build and publish automation toolset.
As mentioned, the easiest way to build DacPac file on a linux agent is done via MSBuild.Sdk.SqlProj
Go to your database project directory in parallel to .sqlproj file create a directory like DB.Build under it create DB.Build.csproj copy.pase the content as below
<Project Sdk="MSBuild.Sdk.SqlProj/1.1.0"> <!-- This will pull in the required tools and dependencies to build a .dacpac with .NET Core -->
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Content Include="..\src\DB\masterdata\**\*.sql" /> <!-- link in the new .csproj to the .sql scripts in your existing database project -->
</ItemGroup>
</Project>
After run you will see dacpac file appears under DB.Build/bin/Release/netstandard2.0/DB.Build.dacpac
Here's my build agent output (Ubuntu agent on Azure devops)
Starting: SQL DB build Release
==============================================================================
Task : .NET Core
Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version : 2.187.0
Author : Microsoft Corporation
Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
Info: .NET Core SDK/runtime 2.2 and 3.0 are now End of Life(EOL) and have been removed from all hosted agents. If you're using these SDK/runtimes on hosted agents, kindly upgrade to newer versions which are not EOL, or else use UseDotNet task to install the required version.
/opt/hostedtoolcache/dotnet/dotnet build /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/RecommenderAPI.DB.Build.csproj -dl:CentralLogger,"/home/vsts/work/_tasks/DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b/2.187.0/dotnet-build-helpers/Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll"*ForwardingLogger,"/home/vsts/work/_tasks/DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b/2.187.0/dotnet-build-helpers/Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" --configuration Release /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=/home/vsts/work/1/recommender-service-cicd/DacPac/
Microsoft (R) Build Engine version 16.5.0+d4cbfca49 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restore completed in 51.72 ms for /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/RecommenderAPI.DB.Build.csproj.
Using package name RecommenderAPI.DB.Build and version 1.0.0
Using SQL Server version Sql150
Deleting existing file /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/obj/Release/netstandard2.0/RecommenderAPI.DB.Build.dacpac
Writing model to /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/obj/Release/netstandard2.0/RecommenderAPI.DB.Build.dacpac
RecommenderAPI.DB.Build -> /home/vsts/work/1/s/src/RecommenderAPI.DB/RecommenderAPI.DB/RecommenderAPI.DB.Build/bin/Release/netstandard2.0/RecommenderAPI.DB.Build.dacpac
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:01.71
Finishing: SQL DB build Release
Note: Make sure to restore you NuGet packages in step prior to build
I'm trying to integrate SourceLink into Visual Studio Team Services by using https://github.com/ctaggart/SourceLink
I have problems with it since the package seems unable to parse the URL of a VSTS repository.
Build started 8/22/2017 11:58:18 AM.
1>Project "D:\Repos\Core\classic-stats\src\Acme.Stats\Acme.Stats.csproj" on node 1 (Build target(s)).
1>SourceLinkCreate:
git rev-parse --show-toplevel
D:/Repos/Core/classic-stats
git config --get remote.origin.url
https://acme.visualstudio.com/DefaultCollection/Core/_git/classic-stats
git rev-parse HEAD
8c6a68b325cf10b67332aa2ea15db952a88d027d
SourceLinkUrl:
unable to convert OriginUrl: https://acme.visualstudio.com/DefaultCollection/Core/_git/classic-stats
1>Done Building Project "D:\Repos\Core\classic-stats\src\Acme.Stats\Acme.Stats.csproj" (Build target(s)) -- FAILED.
Build FAILED.
0 Warning(s)
0 Error(s)
AFAIK there's only support for GitHub and BitBucket, am I right?
Has anybody been able to integrate this into TFS builds?
Thanks
As Skorunka stated in his comment, SourceLink now has support for VSTS (recently renamed Azure DevOps)
Install the Microsoft.SourceLink.Vsts.Git Microsoft.SourceLink.AzureRepos.Git package in your project and add the following to your .csproj file
<PropertyGroup>
[...]
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
<PublishRepositoryUrl>true</PublishRepositoryUrl>
<EmbedUntrackedSources>true</EmbedUntrackedSources>
</PropertyGroup>
Configure your Build Pipeline to generate your Nuget package using the dotnet pack command. SourceLink doesn't work yet with the Nuget pack (based on my tests).
Push your changes to your Azure DevOps server and let the build pipeline generate your Nuget package and push it to your Nuget feed.
In Visual Studio go to tools -> Option -> Debugging -> General and ensure that
Enable just my code is not checked
Enable SourceLink support is checked
Then in any other project, install your Nuget package.
When you'll try to step into some code defined in your package's DLL, Visual Studio will ask if you want to Download source code and continue debugging. It will authenticate to your Azure DevOps server using your Git credentials, download the source code, and let you debug it.
As of preview3 dotnet new produces a csproj, and both dotnet restore and dotnet build fail against a project.json and/or an xproj.
For instance, running dotnet restore against a directory that has both a project.json and an xproj gives this error.
...xproj(7,3): error MSB4019: The imported project "C:\Program Files\dotnet\sdk\1.0.0-preview3-004056\Extensions\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Further, running it against a directory that has only a project.json gives this error.
MSBUILD : error MSB1003: Specify a project or solution file. The current working directory does not contain a project or solution file.
Without using Visual Studio, how can we convert an existing project.json and/or xproj to a csproj?
There is a dotnet migrate command.
The dotnet migrate command will migrate a valid Preview 2 project.json based project to a valid Preview 3 csproj project.
We can find detailed help on this command by running dotnet migrate -h (even though dotnet -h does not list the command).
I used sdkman to install groovy which went fine. Where is the installed package now? I need the path for it. I am on Ubuntu 14.04.
I've checked it on my system. It should be located in $HOME/.sdkman/candidates/.
I think the best way would be to use SDKMan's home command:
https://sdkman.io/usage#home
Something like this (taken from the above page):
$ sdk home java 11.0.7.hs-adpt
/home/somedude/.sdkman/candidates/java/11.0.7.hs-adpt
Upon installation, SDKMAN creates an environment variable $SDKMAN_DIR which points to the installation directory.
Usuall it's ~/.sdkman
After you have run source $HOME/.sdkman/bin/sdkman-init.sh.
You can see the sdkman "installation" by running:
declare -f
$HOME on mac is /Users/<users>
Where's SDKMan installed:
echo #SDKMAN_DIR
Where did it just install gradle? (or some other package)
which gradle
SDKMAN stores file in $HOME/.sdkman/candidates/ as Tom mentioned and this answer goes into more detail.
To find where SBT 1.3.13 is installed, type sdk home sbt 1.3.13. It'll return something like /Users/powers/.sdkman/candidates/sbt/1.3.13.
The arguments to the sdk install command align with where the files are stored in $HOME/.sdkman/candidates.
sdk install java 8.0.272.hs-adpt stores files in $HOME/.sdkman/candidates/java/8.0.272.hs-adpt.
sdk install sbt 1.3.13 stores files in $HOME/.sdkman/candidates/sbt/1.3.13.
When you run sdk install, the downloaded binaries get saved in $HOME/.sdkman/archives. For example, $HOME/.sdkman/archives/java-8.0.272.hs-adpt.zip and $HOME/.sdkman/archives/sbt-1.3.13.zip.
Some of the binaries are pretty big and can end up taking a lot of space on your computer. You should periodically delete them with the sdk flush archives command. Once you install the software, you don't need the binaries anymore. See here for more details.