We have our source code (ASP.NET Core) within a SVN repository. Now for Continuous Integration, we want to use TFS to build and deploy to Azure WebApp. We can't migrate our code to TFS.
Is this possible?
Subversion is a natively supported repository type when defining builds since TFS 2015 Update 1. You should be able to choose it on the "Repository" tab.
There is a walkthrough available on VisualStudio.com.
You can build code you manage in Subversion in TFS 2017. You must install the Subversion client on your build agents. Check: https://www.visualstudio.com/en-us/docs/build/define/repository#subversion
In the Repository of Build Definition, choose Subversion type:
Related
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.
My team uses Visual Studio Team Services to manage our source code in a TFS repository. The solution contains multiple web apps. I am trying to configure Continuous Integration and Continuous Deployment for this solution such that each web application is deployed to the correct Azure web app after a successful build. I've configured the BuildDefinition to build $/MyProduct/MAIN/MySolution.sln. I've defined the following parameters to MSBuild based on some MSDN articles I found on this subject:
/p:DeployOnBuild=true
/p:WebPublishMethod=Package
/p:PackageAsSingleFile=true
/p:SkipInvalidConfigurations=true
/p:PackageLocation="$(build.stagingDirectory)"
The build steps include a Visual Studio Build step, a Visual Studio Test step (currently disabled to minimize complexity), an Index Sources and Publish Symbols step (which I don't think I really need), and finally, a Copy and Publish Build Artifacts step.
I am able to build this solution using this configuration. I can see the build results, the build log, build details, etc. When I look at the artifacts that are created, I see two artifacts: "drop" and "build.sourceLabel" If I explore the drop file using the Artifacts Explorer, I find all of my projects in this drop file, and for the web app projects, I can navigate into the webapp1\obj\QA\Package\PackageTemp\bin folder and see all the DLL's etc. for the web app.
What I don't see is one zip file per web app, which is what the Release feature of Visual Studio Team Services is expecting.
I would like to know how to modify my current configuration so that I can generate the correct artifacts from the Build step so that I can create the correct Release Wep App Deployment tasks to deploy each web app to the correct web app in my environment.
This is all being done with Visual Studio 2015 and Visual Studio Online (Team Services).
To test your situation I used Visual Studio 2015 and created 3 new web projects in the same solution and checked into VSTS. I then created a new build using the Azure Website deployment template. Many people miss that we have Build and Deployment templates on the Create New Build Definition dialog. The reason I use the Azure Website template is because I can never remember the msbuild arguments to pass in. You can simply delete the Azure Web App Deployment task if you are going to use RM.
One change I always make to the msbuild arguments is the PackageLocation. I always change mine to $(BuildConfiguration). That way I can build both Debug and Release at the same time should I desire.
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(BuildConfiguration)"
Finally I change my Copy and Publish Build Artifacts task to search for just “**\*.zip”. Leave the Copy Root empty and run your build.
When your build completes you will have one zip per project under the [ProjectName]/[Configuration]/projectName.zip when you explore your artifacts.
If you have further questions you can ping me on Twitter #DonovanBrown
I have an ASP.NET Web API project created on Windows using Visual Studio. How can I set this up for use with DNX/DNVM (on a Mac)?
Switching to Git solved the source control compatibility with TFS. But I wasn't able to find references to getting a project working across both these development environments.
I'm assuming as a first step the project will have to be migrated to ASP.NET 5/vNext but wondering other problems lurk around the corner with different project members using different environments.
I get an error when I run - git:(master):dnx . kestrel
As you mentioned yes you will have to migrate any namespace changes. I have a project that is developed across both. Also changing csproj files to xproj. Support is coming for some kind of interop between the different project types but its not here yet.
For build, publish, deploy from git without relying on VS publish capabilities or MSBuild you can follow my blog post here.
Basically you use DNU to publish and then kudu to deploy.
Working on a Windows Store App which is utilising SQLite for WinRT. Local builds work fine due to the installation of the VS2012 Extension SQLite for Windows Runtime.
This adds 2 SDK references into the project config which points to the local file system (not part of the solution). But TFS 2012 Build freaks out saying that the build is broken as it can't find the SQLite and C++ dlls.
I am using the MS hosted TFS so installing the SDKs on the build server is not an option.
Any ideas?
I've run across similar issues when trying to build WinRT projects using the TFS Hosted Build Server.
In the end, this article was the winner:
http://blog.novotny.org/2012/03/24/how-to-use-extension-sdks-per-project/
The solution is to put the libraries in version control in a “libs” directory. NuGet does this for existing libraries in a \packages directory at the solution-level; it does not yet support Extension SDKs. The good news is that both Visual Studio 11 and MSBuild already support defining additional locations for Extension SDK’s by overriding the SDKReferenceDirectoryRoot variable. The key is to add the override after the element near the end of the csproj/vbproj file like this:
<PropertyGroup>
<SDKReferenceDirectoryRoot>$(SolutionDir)\libs;$(SDKReferenceDirectoryRoot)</SDKReferenceDirectoryRoot>
</PropertyGroup>
With that in place, you can then put your Extension SDK files alongside your solution:
\libs\Windows\v8.0\ExtensionSDKs[SDKName][SDKVersion]\…
Once there, it will be available in the Visual Studio Add References dialog like any other Extension SDK.
Now my SDK references don't need to be manually installed on developers machines or build servers.
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.