ASP.NET Website Project auto deploy with TFS 2013 build - asp.net

I have a ASP.NET Webforms Website project(note this is NOT WebApplication project i.e. there is no .csproj).
I want to do a auto deploy, file system to our network share.
I created a profile and so there is website.publishproj file and profile xml.
I tried adding this in MSBuild arguments in Build Definition:
website.publishproj /p:DeployOnBuild=true
/p:PublishProfile=MyDevProfile /p:VisualStudioVersion=12.0
I get this error:
MSBUILD : error MSB1008: Only one project can be specified. Switch:
website.publishproj
Any idea what am I doing wrong? I believe this has something to do with Website project type.
This is something I read: How to use command line msbuild to deploy VS2012 Web Site project without precompiling it?
Here is the command:
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe /nologo
/noconsolelogger
"E:\Builds\1\TP1\MyWebsite_Dev\src\Websites\MyWebsite\MyWebsite.sln"
/nr:False /fl
/flp:"logfile=E:\Builds\1\TP1\MyWebsite_Dev\src\Websites\MyWebsite\MyWebsite.log;encoding=Unicode;verbosity=normal"
/p:SkipInvalidConfigurations=true website.publishproj
/p:DeployOnBuild=true /p:PublishProfile=DropToDemoProfile
/p:VisualStudioVersion=12.0 /m
/p:OutDir="E:\Builds\1\TP1\MyWebsite_Dev\bin\"
/p:VCBuildOverride="E:\Builds\1\TP1\MyWebsite_Dev\src\Websites\MyWebsite\MyWebsite.sln.vsprops"
/dl:WorkflowCentralLogger,"C:\Program Files\Microsoft Team Foundation
Server
12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;BuildUri=vstfs:///Build/Build/35;IgnoreDuplicateProjects=False;InformationNodeId=13;TargetsNotLogged=GetNativeManifest,GetCopyToOutputDirectoryItems,GetTargetPath;LogWarnings=True;TFSUrl=http://mytfs:8080/tfs/colletionname;"*WorkflowForwardingLogger,"C:\Program
Files\Microsoft Team Foundation Server
12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;"
/p:BuildId="7d23530d-7349-406f-98b7-5d4f0b9f4101,vstfs:///Build/Build/35"
/p:BuildLabel="MyWebsite_Dev_20141122.13" /p:BuildTimestamp="Sun, 23
Nov 2014 01:22:05 GMT"
/p:BuildSourceVersion="LMyWebsite_Dev_20141122.13#$/TP1"
/p:BuildDefinition="MyWebsite_Dev"

You're trying to build the solution (MyWebsite.sln) and the project (website.publishproj) simultaneously as part of the same MSBuild command at least according to the arguments being passed.
You can run msbuild website.publishproj /pp:website.pp.publishproj to see what targets you can call in website.pp.publishproj or what properties to override.
You can run set MSBUILDEMITSOLUTION=true && msbuild MyWebsite.sln to see what targets you can call in MyWebsite.sln.metaproj and MyWebsite.metaproj or what properties to override.
Your DeployOnBuild command is fine and should work, I'm guessing your TFS build config is pointing to the .sln and passing website.publishproj as an argument rather than the primary target of the build, so either repoint it to build the .publishproj directly or... well, there doesn't seem to be any alternative, you can try adding a new configuration and editing the .sln with new AspNetConfiguration and MyDevProfile.AspNetCompiler.TargetPath but then you're just asking for trouble.

You need to upgrade your Web Site to a Web Application in order for any of this to be automatic.
Its a fairly simple procedure and even on sites with thousands of pages I have completed the migration in only a few days of one persons time without impacting other devs.
Web Site functionality has been feature complete for over 10 years. While it still existing in the product for back-compat I would not recommend using it.

Related

How to exclude folders/projects from dotnet core publish task in Azure Build Pipeline (Classic version)?

I have an Azure DevOps GIT Repo with three different types of projects. Structure looks as follows;
Repository Structure
I have a Build Pipeline (Classic, not YAML) to build only the .Net Core Project as below.
Pipeline
The pipeline settings is pointed to consider only the NetCoreProject. The Restore, Build & Test tasks executes successfully. However, when it comes to the 'Publish' task the pipeline fails as it considers the entire repository (all projects) and not just NetCoreProject.
Actual cause of failure is in NetCPPProject folder there are some files without any extension (makefile, shortcut files, etc.) which the Publish task is not identifying and failing with below error.
##[error]Error: Failed find: ENOENT: no such file or directory, stat 'D:\a\1\s\NetCPPProject\inc'
Note: inc is a shortcut file (without any extension) and it is required to be present in the folder.
I tried following which did not work;
Added .artifactignore to ignore other folders but the .Net Core 'Publish' task seems not to consider that.
Tried specifying the arguments to Publish tasks to consider only the NetCoreProject .sln file and also .csproj file, but issue still occurs with same error message.
Reconfirmed the file exists in Build.SourceDirectory with a command line task.
Question is, how to make .Net Core 'Publish' task to exclude NetCPPProject and only consider NetCoreProject?
how to make .Net Core 'Publish' task to exclude NetCPPProject and only consider NetCoreProject?
To achieve this goal, you could try the following steps:
Step1: Disable Publish web projects option in Dotnet Publish task.
Step2: Set the target csproj file in Path to project field
For example:
Repo:
Result:

MSBuild not compiling with both /p:Configuration=Release and -p:Configuration=Debug

We are attempting to install a clean build of the newest version of Kentico (12) on Azure, using Kudu, in DEBUG configuration. We traditionally accomplish this by setting SCM_BUILD_ARGS to -p:Configuration=Debug, and all is well. But for some reason in this newer version, the project fails to compile, and I see that this is the command being run:
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "C:\Users\User\Documents\GitHub\Project\CMS\CMSApp.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="C:\local\Temp\8d6d315018f5ff9";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false /p:SolutionDir="C:\Users\User\Documents\GitHub\Project\.\\" -p:Configuration=Debug
Notice both Configuration=Release and Configuration=Debug. The compilation errors are things like Invalid expression term 'string' on the following line of code:
bool licenseOK = LicenseHelper.CheckLicenseLimitations(FeatureEnum.Ecommerce, out int skuCount, out int maxSKUCount);
This doesn't highlight at all in Visual Studio in Debug or Release mode. I am also able to reproduce locally (as shown in my paths above), and if I change the two configurations to both be the same (regardless of whether I choose Debug or Release), it compiles just fine.
What I know I can do is create my own custom deployment command script file as a work-around, but I guess I don't understand why the above MSBUILD command isn't working in the first place.
Any ideas as to why this would work great for all of my ASP.NET projects prior to this one? One thing I know is that Kentico recently included the Roslyn compiler, which I am unfortunately not that familiar with - could that be part of the issue?
UPDATE #1: It appears all of the compilation errors have to do with code that is only valid in C# 7.0. That could be a clue.
It all came down to the fact that the newer versions of Kentico had code that was only valid in C# 7, and required MSBuild 15 to compile. Here's how I was able to set up Kudu:
Add a file named .deployment in the root of my repo, containing only the contents below. This tells Kudu to use a custom deployment script.
Download the deploy.cmd file from my Azure App Service via FTP to the root of my repo, and update it per https://github.com/projectkudu/kudu/issues/2350#issuecomment-373817740 to use the MSBuild 15 path. Details below.
.deployment file contents
[config]
command = deploy.cmd
deploy.cmd updates
1 - Add -MSBuildPath "%MSBUILD_15_DIR%" to nuget call. Example:
nuget.exe restore "{your .sln file path}" -MSBuildPath "%MSBUILD_15_DIR%"
2 - Replace %MSBUILD_PATH% with %MSBUILD_15_DIR%\MSBuild.exe in both occurrences under step 2. Build to the temporary path
This was all that was needed in order to get the build to complete.
As Keith mentions, it was a compatibility issue with C# 7.0 that Kentico 12 uses. This SO thread mentions that you need to run MSBuild version 15 for C# 7.0 code. I ran a similar debug command for my local Kentico 12 project using MSBuild 15, and it succeeded.

Deploy from command line using MSBUILD and or MSDEPLOY (.NET 3.5)

I'm trying to get my website deployed by a Jenkins job.
I'm using the following command line sentence, with no success:
"C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe" myproj.csproj /p:DeployOnBuild=true
I've also tried:
"C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe" myproj.csproj /p:Configuration=Debug /p:OutputPath="obj\debug" /p:DeployIisAppPath="Default Web Site/demo"
None works although my project is compiled properly.
WHen I go to C:\inetpub\wwwroot nothing new is there. I want my site to start running and be accesible from my browser in Localhost.
You can use MSDeploy to deploy your web app using the following MSBuild arguments
/p:Configuration=release
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=https://targetServer:8172/MsDeploy.axd
/p:DeployIisAppPath=MySite
/p:AllowUntrustedCertificate=True
/p:Username=
/p:AuthType=NTLM
MSDeploy, however, has proven to be better solution for us. We use MSBuild to create an MSDeploy package and then we can deploy that package to many environments using MSDeploy.exe. Build once, deploy many. Here is an overview of WebDeploy which may be helpful:
http://dotnetcatch.com/2016/02/25/the-anatomy-of-a-webdeploy-package/
Make sure that you are adding the correct parameters after the MSBuild command, such as /p:DeployOnBuild=true /p:PublishProfile="XXXProfile", but the most important is to add the MSBuild.exe path to your %PATH% environment variable.
Having the MSBuild.exe path added to your %PATH% system environment variable the only thing you need to do is call:
msbuild myproject.csproj /p:DeployOnBuild=true /p:PublishProfile="MyProfile", where MyProfile is the generated publishing profile with Visual Studio and can be found under MyProject\Properties\PublishProfiles folder.

MSBuild does not build the PDB files

I have a solution converted from VS2010 to VS2012. In the Release build, I want it to produce PDB files and full debug symbols because I need to run remote debugging in a production environment.
So I set Debug Info to full for Release configuration. I also confirmed the followings are in the project manifest file:
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimized>true</Optimized>
But when I run MSBuild, the package it creates doesn't include the PDB files. However, if I use Visual Studio's Publish feature with Release configuration, I end up with PDB files on the target web server. What could be wrong with the Build command?
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe "C:\MyWebApp.csproj"
/t:rebuild;package
/p:OutPath="C:\MyWebApp\obj"
/p:OutputPath="C:\MyWebApp\bin"
/p:Configuration=Release
/p:Platform=AnyCPU
I tried turning off the Optimized bit, but that didn't help.
Try adding
/p:DebugSymbols=true
/p:DebugType=full
If you are publishing a web application then you should also add:
/p:ExcludeGeneratedDebugSymbol=false
You can access this straight from the command line:
msbuild.exe "C:\\MyWebApp.csproj"
/t:rebuild;package
/p:OutPath="C:\\MyWebApp\\obj"
/p:OutputPath="C:\\MyWebApp\\bin"
/p:Configuration=Release
/p:Platform=AnyCPU
/p:DebugType=pdbonly

"Can't find the valid AspnetMergePath" on Visual Web Developer Publish?

I am wanting to use Visual Web Developer Express 2010 to publish a website, pre-compiled to a remote server over FTP using the following settings:
Deploy only files needed to run this application
Precompile this application before publishing
Allow website to be updatable
No databases are being deployed
Site is being deployed as file hierarchy, not as .zip package
My first build/deploy seemed to have gone well, but after my second compilation I receive the following error:
Transformed web.config using C:\path_to_site\Web.Debug.config into obj\Debug\TransformWebConfig\transformed\web.config.
Copying all files to temporary location below for package/publish:
obj\Debug\AspnetCompileMerge\Source.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.5\Web\Transform\Microsoft.Web.Publishing.AspNetCompileMerge.targets(132,5): Error : Can't find the valid AspnetMergePath
And here's a subset of the content of the Microsoft.Web.Publishing.AspNetConfigurationMerge.targets file:
<Target
Name="GetAspNetMergePath"
DependsOnTargets="$(GetAspNetMergePathDependsOn)"
Condition ="'$(GetAspNetMergePath)' != 'false'">
<PropertyGroup>
<AspnetMergeName>aspnet_merge.exe</AspnetMergeName>
<AspnetMergePath Condition="Exists('$(TargetFrameworkSDKToolsDirectory)$(AspnetMergeName)')">$(TargetFrameworkSDKToolsDirectory)</AspnetMergePath>
</PropertyGroup>
<Error Condition="'$(AspnetMergePath)' == '' Or !Exists($(AspnetMergePath))"
Text="Can't find the valid AspnetMergePath" />
</Target>
EDIT: Changing the publish settings to delete all existing files before publishing does not fix the problem after all. I'm assuming that the problem is local for now because of this.
There does not appear to be an AspMergePath tag in my web.config. I am not aware if I am supposed to manually add the tag. However, the path "obj{publish setting}\AspnetCompileMerge\Source" does exist in my project.
And in case it matters, my project name is "TestProject.NET"
Your feedback is appreciated.
I hit the same problem. Searched through all microsoft related sites, found a lot of complaints and no intention from microsoft to fix it.
Here how I worked it around at my system. Edit the Microsoft.Web.Publishing.AspNetConfigurationMerge.targets file and add the following line. Please make sure that the Microsoft SDK path is the same on your PC, if not then change it:
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\</TargetFrameworkSDKToolsDirectory>
Here is how it should look like:
<Target
Name="GetAspNetMergePath"
DependsOnTargets="$(GetAspNetMergePathDependsOn)"
Condition ="'$(GetAspNetMergePath)' != 'false'">
<PropertyGroup>
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\</TargetFrameworkSDKToolsDirectory>
<AspnetMergeName>aspnet_merge.exe</AspnetMergeName>
<AspnetMergePath Condition="Exists('$(TargetFrameworkSDKToolsDirectory)$(AspnetMergeName)')">$(TargetFrameworkSDKToolsDirectory)</AspnetMergePath>
</PropertyGroup>
<Error Condition="'$(AspnetMergePath)' == '' Or !Exists($(AspnetMergePath))"
Text="Can't find the valid AspnetMergePath" />
What you need is aspnet_merge.exe, tool that is distributed as part of Windows SDK. It's intended to precompile sites, so you can either turn that precompilation off, or install proper version of Windows SDK. Reference is to the Wikipedia, because of nice prepared links to the download pages. You don't need to download/install everything (it's huge), just download web installer and select .Net tools, it will take around 50 megabytes.
Please, notice that bundled with Visual Studio 2010 Windows SDK ver. 7.0A isn't available to separate download, so you'll have to either install Visual Studio on your build server, or tweak something as described in answers to "Running MSBuild fails to read SDKToolsPath".
Here is a solution that does not require changing the targets file. The workaround from http://connect.microsoft.com/VisualStudio/feedback/details/786492/publish-cant-find-the-valid-aspnetmergepath suggests passing additional properteries to msbuild. I was able to get it to work using this:
msbuild website.publishproj /p:DeployOnBuild=true /p:PublishProfile=Release /p:VisualStudioVersion=12.0 /p:AspnetMergePath="C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\"
The key here is the AspnetMergePath property, which you may need to change if the Windows SDK is installed in a different location. If I include the GetAspNetMergePath property from the workaround it fails, but that may be needed depending on the SDK version.
One workaround for all this stuff [including having to install the SDK etc] is to disable the Precompile On Publish option, which requires AspNetMerge to be present even if you're not specifying that you want stuff to be merged in the ultimate output.
I was going to great lengths to figure out how to turn it off, poring over the options dialog and Reading the Friendly Manual to confirm I had it turned off for ages only to realize it was the checkbox outside:
Unchecking yields the following changes to the .pubxml:
- <PrecompileBeforePublish>True</PrecompileBeforePublish>
- <EnableUpdateable>True</EnableUpdateable>
- <DebugSymbols>False</DebugSymbols>
- <WDPMergeOption>DonotMerge</WDPMergeOption>
Which worked for me.
NB it is however critical to have as covered here both the Web (which will silently make publishing via /p:DeployOnBuild inert) and the WebApplications (which will give a compiler error) subfolders present under %Program Files (x86)%\MSBuild\Microsoft\VisualStudio\v14.0 (assuming Visual Studio 2015 tooling) for publishing to successfully generate packages
I hit the same problem.
Edit the Microsoft.Web.Publishing.AspNetConfigurationMerge.targets file and add the following line. Make sure run editor with Administrator Rights.
Looks the correct versiĆ³n Visual Studio in my case VS2013.
x64
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\</TargetFrameworkSDKToolsDirectory>
x86
<TargetFrameworkSDKToolsDirectory>C:\Program Files\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\</TargetFrameworkSDKToolsDirectory>
And it Works! I can compile my Project.
In my case was missing. It happened after updating Visual Studio 2017 to 15.7.5. Before that it was working fine. I have to add
<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\</TargetFrameworkSDKToolsDirectory>
It was at Line no 129 in Microsoft.Web.Publishing.AspNetCompileMerge.targets
change targetFramework ...
<compilation debug="true" targetFramework="4.8"/>
<httpRuntime targetFramework="4.8"/>

Resources