sayedihashimi

sayedihashimi

Question: How can I ensure that all projects only use a specific set of nuget packages and versions? I'm using VS2017.

The way that I would handle this is to add a (directory.build.targets)[https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-and-directorybuildtargets] to help in this scenario.

The idea is that you will add an msbuild .targets file in the source root named directory.build.targets. In that file you can inject a target to be run before the build starts. For example,

sayedihashimi

Scenario:

• I have a web project that I want to publish to multiple IIS sites
• Publish in VS should publish to devs local IIS server (MSDeploy)
• Publish from CI/CLI should publish to remote env (MSDeploy)
• CI/CLI and VS publish should be the same
• Building the solution takes ~3 min and should only be performed once
• Config files need to be transformed based on the dest env

Question:

How can I accomplish this?

sayedihashimi

--- template report ---

Name                                                 DownloadCount Percent overall
----                                                 ------------- ---------------
Microsoft.AspNetCore.SpaTemplates                            44876 65.4 %         
Microsoft.DotNet.Web.Spa.ProjectTemplates                     6253 9.1 %          
libyear                                                       1860 2.7 %          
Boilerplate.Templates                                         1600 2.3 %          
IdentityServer4.Templates                                     1136 1.7 %          
Amazon.Lambda.Templates                                       1122 1.6 %          

sayedihashimi

[cmdletbinding()]
param()

# to run this script:
#  (new-object Net.WebClient).DownloadString("https://gist.githubusercontent.com/sayedihashimi/899ed1a47953ea6a45f60220687cfdd6/raw/b3ad6ab230b5c4a9cf5b39d3142fc7b36df8c54f/run-dotnetnew-ux.ps1") | iex

function StartDefault{
    [cmdletbinding()]
    param()
    process{

sayedihashimi

[cmdletbinding()]
param()

$global:machinesetupconfig = @{
    MachineSetupConfigFolder = (Join-Path $env:temp 'SayedHaMachineSetup')
    MachineSetupAppsFolder = (Join-Path $env:temp 'SayedHaMachineSetup\apps')
    BaseChocoPackages = @(
        'boxstarter',
        'boxstarter.winconfig'
        'git.install',

sayedihashimi

[cmdletbinding()]
param()

function DownloadTablebases{
    [cmdletbinding()]
    param(
        $baseUrl = 'http://www.chesskit.com/download/nalimov',
        $allFilename = 'all.txt',
        $downloadRoot = ($pwd)
    )

sayedihashimi

Template dependencies

• from bower
• from gulp

Name	Version used	Current Stable	Next release
bootstrap	3.3.6 ✅	3.3.6 Nov 2015	3.3.7 bootstrap 4 - currently in alpha
jQuery	2.2.0 ⚠️	2.2.3 April 2016	3.0 (no date) 3.0.0-beta1 Jan 2016
jquery-validation	1.14.0 ⚠️	1.15.0 Feb 2016	2.0.0 (no d

sayedihashimi

Thoughts on command line project creation

Note: what you'll find below are just some ideas. I'm writing these down so that I can share it at https://github.com/dotnet/cli/issues/2052 with the goal to change how we are approaching templates. I'm not directly woring in this area. However, I am responsible for ASP.NET template content in Visual Studio and yo aspnet.

With dotnew new we are interested in enabling an experience for users to create new projects from the command line. Creating projects from the command line is not a new concept, it's been around for a while especially on the web development side. One example of a successful command line project generator is yeoman. Yeoman is a super popular tool for developers, and if dotnet new is as successful as yeoman, IMO, that would be a really wonderful thing. To enable a meaningful discussion on dotnet new let's start by taking a look at a typical user experience when using yeoman to create a new project. Below are typic

sayedihashimi

In summary, WebDeploy (the marketing term) includes MSDeploy binaries, MSBuild extensions (*.targets files), Visual Studio extensions and the Web Deployment Agent Service.

The targets are not really a part of Web Deploy but instead of the Visual Studio Web Projects which are implemented in MSBuild and then invoke MSDeploy

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild /t:Package

You're using an old copy of msbuild.exe but for your scenarios it's likely OK.

FYI the deploy.cmd file has some bugs and in some scenarios doesn't work well. I'd only use that as a starting point or for basic scenarios