I installed Visual Studio 2017.
I wanted to clone a repository and try in my local system.
Suppose i want to clone this. repo (Not mine.) Is it possible in one step?
Or else do i need to write step by step actions and necessary codes to run the project?
By checking NuGut package manager to auto download packages on build time will
work? I am new in ASP.Net. Is there any way to run the project in local system by just cloning.
EDIT:- Tried to restore packages
PM> dotnet restore
Welcome to .NET Core!
---------------------
Learn more about .NET Core: https://aka.ms/dotnet-docs
Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli-docs
Telemetry
---------
The .NET Core tools collect usage data in order to help us improve your experience. The data is anonymous and doesn't in
clude command-line arguments. The data is collected by Microsoft and shared with the community. You can opt-out of telem
etry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.
Read more about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry
ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only). For establishing trust on other
platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.
C:\Users\win7.system3\Documents\Visual Studio 2013\Projects\localhost_54920\localhost_54920.sln : Solution file error MS
B4249: Unable to build website project "SAMP". The ASP.NET compiler is only available on the .NET Framework version of MS
Build.
First of all, you'll need .NET Framework 4.6.1 installed in your machine.
Short answer
Having that installed, you should be able to open the project/solution with Visual Studio, build it* and run it from there.
Long answer
If that was a .NET Core project, without Visual Studio it would be as easy as:
git clone https://github.com/sarn1/example-aspnet-mvc
cd example-aspnet-mvc\ComicBookGallery
dotnet run
dotnet run will restore (dotnet restore) the dependencies, build (dotnet build) the project and run it.
However, that's not the case, so you can only:
Restore the nuget packages using Visual Studio or nuget.exe cli.
Compile it* using or msbuild (use Developer Command Prompt for Visual Studio to be able to easily access it).
Run it... from Visual Studio, which makes the rest of the process kind of worthless.
git clone https://github.com/sarn1/example-aspnet-mvc
cd example-aspnet-mvc
nuget.exe restore
msbuild /t:build
* You may need to apply these changes to make the project compile.
Related
We have for a while been building various web projects with AzureDevops and self hosted build agents.
Today I had to add a new build, consisting of a windows service written in .net core 3.1. This service has to be installed by our customers, so we have to provide it in a friendly installable way. As some of our developers were already used to handle MSI/*.vdproj projects, they added a vdproj into the *.sln to manage that. On a developper machine, this is not a problem even with VS2019: you just have to use the relevant VS studio extension...
But when it comes to building that in a CI/CD context, this becomes a real challenge. I quickly understood that we can't use MSBuild at all for that and found some alternative using directly Visual Studio (devenv)... Inspired by this thread (still opened), I came up with the following command line:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\devenv" [...]\MySolution.sln /build "Release" /Project MyInstallationProject
This worked fine both on my developer machine and even on the build agent machine. But when I add it into a build pipeline as a command line task, it seems to hang, and after a while I get the following result for the job:
##[error]The job running on agent <MyAgent> ran longer than the maximum time of 60 minutes. For more information, see https://go.microsoft.com/fwlink/?linkid=2077134
What can I do to make it work?
What are the best practices for generating a self installable in a CI/CD context? (Is MSI still relevant? )
As a workaround, you can try to install the extension Build VS Installer and use the task DutchWorkz - Build VS Installer(s) to build Visual Studio Installer Project in Azure Pipelines.
Here are some tickets(ticket1, ticket2) with similar issue you can refer to.
We developed our application and tested over DotNet core 3.1.101 and it was working fine but what happened is Microsoft updated dotnet core to 3.1.111 and it breaks our application and we are asking customer to downgrade the core version manually that doesn't seem to be good idea.
Can somebody Wixsharp/.Net expert suggest, how can we avoid this problem? Can we have side by side installation of dotnet core and use the desired on with our application? If yes, How can we do it?
If you are really dependent of the specific net core version, the best solution to you will be to use self-containing publishing (https://learn.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained). This will create the solid bundle from your code and the your current net core version. On the client machine your app will use the net core, which is bundled with app. User may have other versions of net framework/net core installed, but these versions will not affect your app in any way.
For example, the following will create 64-bit executable for Windows
dotnet publish -r win-x64.
After you got your bundle from publish command, you need just pack the whole bundle with wix as usual. Not need to perform additional steps to install net core.
I saw a couple of similar questions but so far I found no single answer to the problem of integrating the publishing step with my build process. Unfortunately the dotnet publish command rebuilds the project again meaning that if I put the "dotnet publish" command in the project's Post-Build steps I get an infinite loop of building retries.
What I want to achieve is to get an exe built for my .NET Core 2.2 Console App for a few selected environments eg. osx and windows-10, possibly linux too, each in its own folder. Obvious condition is that it has to be integrated with the build, so no extra manuals steps (commands) are required. This has to work from within VS2019 Pro as well in CI (like AzureDevOps).
Is this basic step achievable or .Net core was a major step-back in the progress of software development?
I hope I just miss something and I am just grossly exaggerating. :)
Thanks, Radek
How do I integrate exe publishing with the VS2019 build of the console
.net core 2.2 application?
Actually, I think you do not need to worry about this.
dotnet publish already contains the build process. Publish process will first execute Build and then run publish. In a word, Build is a part of Publish process.
So when you input dotnet publish under Build, you will get an infinite loop of building retries.
Solution
----- Just delete post-build event in xxx.csproj file and just dotnet publish directly and it will run the build process first.
You can test in the local VS and when you right-click on your project-->Publish, it will show the step in the output windwow.
In addition, as far as I know, Azure DevOps has a task called dotnet publish which contains Build.
And if you want to do some msbuild custom target only for publish step, you can add a condition like Condition="'$(DeployOnBuild)'=='true'", it will execute for Publish process rather than the normal build step(right-click on your project-->Build).
<Target Name="testone" Condition="'$(DeployOnBuild)'=='true'" AfterTargets="Build">
xxxxxxxxxxxxxx
</Target>
---------------Update 1----------------
First question
Actually, the build of the publish is the pure process and then publish will copy the content of the build output into publish folder. So the execute program is just from the build output folder.
See the publish log:
So you should not specify a publish target under the build process. This is superfluous.
Second question
To generate this program for Window-10, linux or osx, you can try these command line to publish your project:(Release is the standard release build configuration)
For Win-10:
dotnet publish -r win10-x64 -c Release --self-contained
Linux:
dotnet publish -r linux-x64 -c Release --self-contained
For osx:
dotnet publish -r osx.10.12-x64 -c Release --self-contained
In this way, the project is first built according to the specified runtime and then published.
More info about .NET Core RID Catalog, you can refer to this document.
Update 2
I think you should change the configuration in this package UI:
Then click Save.
Also, when you publish this web project, please try to delete bin and obj folder and then publish it.
Debug: bin\Debug\netcoreapp2.1\publish
Release: bin\Release\netcoreapp2.1\publish
Or you should use dotnet command as I described to publish the project. The path is under Debug or Release folder.
What I want to achieve is to get an exe built for my .NET Core 2.2
Console App for a few selected environments eg. osx and windows-10,
possibly linux too, each in its own folder. Obvious condition is that
it has to be integrated with the build, so no extra manuals steps
(commands) are required. This has to work from within VS2019 Pro as
well in CI (like AzureDevOps).
Is this basic step achievable or .Net core was a major step-back in
the progress of software development?
It's a good idea but as I know what you want is not 100% supported for now.
It seems that your expected scenario is:
Click the Build(F5) button=>Project will be built in different platforms win-x64,win-x86,linux-x64...,also will be published in different platforms automatically with self-contained mode.
But the fact is:
1.Click the Build button(Build(F5) equals to the Build button in project context) will run the Build Target (A default built-in target for each project for build). => dotnet build in command-line.
2.Click the Publish button will run the Publish Target (A default built-in target for each project for publish). => dotnet publish in command-line.
3.If you have any build/publish command in post-build event, it will result in an expected loop. So it's hard to combine publish with build perfectly since they're two actions in VS with different button/behavior/corresponding command. (Only dotnet publish command can recognize --self-contained)
4.To build/publish the projects in parallel, the batch file or msbuild targets file is a good choice.
#1.Build different platforms using one build command see this. #2.Publish different platforms using one command see this. (They both use custom .targets to do the job)
Suggestions:
According to your scenario, I think you can consider using #2. It's not necessary for you to build with different platforms during your normal development.
1.In local VS when you're developing and debugging:
The default build button/option is enough for you to debug.
2.In local VS when you want to publish the project in different platforms:
Use #2 above so that you can publish them using cmd.exe or PS.exe. (Via command dotnet msbuild -restore -t:PublishAllRids)
3.When you're automating the CI pipeline in AzDeops(Also use #2):
A CMD/PS task with dotnet msbuild -restore -t:PublishAllRids command is enough. Dotnet publish will build automatically if we don't pass --no-build argument.
4.Azure Devops Service suggests separate the jobs in different tasks, it's not recommend to Integrate Publish with Build heavily, especially for .net core projects. (Here's official sample about CI for .net core projects.)
I've downloaded Visual Studio with --layout option, and installed it.
Installation was successful with warning, as below,
The product failed to install the listed workloads and components due to one or more package failures.
Incomplete workloads
.NET Core cross-platform development (Microsoft.VisualStudio.Workload.NetCoreTools,version=15.0.26208.0)
ASP.NET and web development (Microsoft.VisualStudio.Workload.NetWeb,version=15.0.26208.0)
Azure development (Microsoft.VisualStudio.Workload.Azure,version=15.0.26208.0)
Mobile development with JavaScript (Microsoft.VisualStudio.Workload.WebCrossPlat,version=15.0.26208.0)
Node.js development (Microsoft.VisualStudio.Workload.Node,version=15.0.26208.0)
Incomplete components
.NET Core 1.0 - 1.1 development tools (Microsoft.NetCore.ComponentGroup.Web,version=15.0.26208.0)
.NET Core 1.0.1 development tools (Microsoft.Net.Core.Component.SDK,version=15.0.26208.0)
Container development tools (Microsoft.VisualStudio.Component.DockerTools,version=15.0.26208.0)
Git for Windows (Microsoft.VisualStudio.Component.Git,version=15.0.26208.0)
Visual Studio Emulator for Android (Component.Android.Emulator,version=15.0.26208.0)
There errors were listed in log file.
Every time I modify the Installer and try to install web components, doesn't work.
I've tried to restart computer, restart the installer.
Nothing works.
After some digging,
I found a solution.
Try to install Visual Studio with setting temp and %temp% folder to short path, like d:\temp.
Step 1 : open cmd with administrator privileges (to ignore administrative privileges error).
Step 2 : execute command - set tmp="d:\temp"
Step 3 : execute command - set temp="d:\temp"
Step 4 : execute vs_community.exe with whatever --layout option you want.
I have many .sqlproj projects that need to be built on our build server. I don't want to install all of Visual Studio on the build server just so I can install SSDT to build these. How can I build .sqlproj projects without a full VS install?
Here's the raw error I get on the build server when trying to build without SSDT intstalled:
C:\MyProject\MyProj.sqlproj (4): The imported project "C:\Program Files (x86)\MSBuild\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.
Answer: Microsoft now has an official NuGet package (see blog post).
Old answer, prior to August 2016; provided in case the NuGet package doesn't work for you:
Install dacframework.msi (x86|x64)
Install SQLDOM.MSI (x86|x64)
Install SQLLS.MSI (x86|x64)
Install SQLSysClrTypes.msi (x86|x64)
Install SSDTBuildUtilities.msi (from the "Administrator Install Point" as setup in step 3 here)
Done!
Source: Headless MSBuild Support for SSDT (*.sqlproj) Projects.
Microsoft SQL Server Data Tools:
http://msdn.microsoft.com/en-us/data/hh297027
Install the tools on build machine to fix the problem.
The Microsoft SQL Server Data Tools team has released a NuGet package named Microsoft.Data.Tools.Msbuild, which helps to build SQL Projects on build servers.
see : https://blogs.msdn.microsoft.com/ssdt/2016/08/22/releasing-ssdt-with-visual-studio-15-preview-4-and-introducing-ssdt-msbuild-nuget-package/
NuGet package : https://www.nuget.org/packages/Microsoft.Data.Tools.Msbuild/
SSDT v12.0.50730.0 requires Visual Studio to be installed beforehand. I found the easiest solution was to install the bare minimum Visual Studio components which were downloaded from MSDN Subscriber downloads:
Visual Studio 2013 Isolated
Visual Studio 2013 Shell
Then SSDT installed fine.
I also used part of the solution outlined above.
* Install dacframework.msi
* Install SQLDOM.MSI
* Install SQLLS.MSI
* Install SQLSysClrTypes.msi
I use MSBuild 12.0 to perform the build which is also available as a separate download.
I was having the exact same issue building a SQL Server project on an Azure DevOps CI/CD pipeline. None of the pre-built build tasks would work for me.
Some answers mention a NuGet package, but I am not sure how can I use it, because SQL Server projects do not allow to install NuGet packages.
I solved this by avoiding to add a SQL Server project to the solution.
I achieved this by using an MSBuild SDK, capable of producing a SQL Server Data-Tier Application package (.dacpac) from the set of SQL scripts. By adding this second project to the solution, I managed to continue taking advantage of linking the project to a live database through SQL Server Object Explorer on Visual Studio. I gave a more detailed explanation about my implementation in this answer.