I used nopcommerce to create a store. And now I want to deploy it on appharbor. But I have a small issue: nopcommerce hasn't .sln file (which have list of files) and appharbor can't build project.
Thank you.
If your repository contains no solution files, it will be treated as a WebMatrix project and deployed straight up. This works fine for Orchard CMS, for example -- see this guide for more details. There's more on the AppHarbor solution file convention here.
You can make the source distribution (which includes a solution file) of nopCommerce build on AppHarbor though. Here's a Git patch with the necessary modifications.
(disclaimer, I'm co-founder of AppHarbor)
Related
So what I'm trying to do is build a .NET Core app with MSBuild, and have it create the web deploy folder but without automatically putting it in a zip file. I can do this for .NET Framework apps by using /p:WebPublishMethod=Package and /p:PackageAsSingleFile=false, it creates the same folder structure but without adding it to a zip file. However with a .NET Core app, it seems to ignore this flag and always zips up the final package.
The reason I do not want it zipped up is I need to add a number of "custom" files to the build before I can deploy it. I can't add the files during the build itself because we have a number of different clients, and they all share the same "base" software, and then the client specific files need to be added afterwords. So I want to build the "base" software, then be able to copy the output folder, add the client specific files, and then zip up that build to be deployed to IIS. This saves a tremendous amount of time because the alternative is doing a new build for each client, even though 95% of the software is the same.
So is there a different way to accomplish this with .NET Core apps?
I've been testing with MSBuild via command line. The solution has a mix of .NET Framework and .NET Core asp.net websites. This is what i'm running:
msbuild.exe "Solution.sln" /nologo /nr:false /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=false /p:SkipInvalidConfigurations=true /p:PreBuildEvent="" /p:PostBuildEvent="" /p:BasePackageLocation="C:\Temp\BuildOutput" /p:platform="any cpu" /p:configuration="release"
This works for the .NET Framework websites, but the .NET Core websites continue to be zipped up
And just a note that the BasePackageLocation is a custom property that sets the PackageLocation to "$(BasePackageLocation)\$(MSBuildProjectName)\" so that each website is put in its own sub-directory
So is there a different way to accomplish this with .NET Core apps?
Sorry but the answer could be negative. This is one issue about publishing .net core projects, it has been reported to Product Team, there might be a long way to go before the fix.
For web deploy package mode in .net core, you'll get WebApplication.deploy.cmd in the same folder where the .zip exists, many commands in the xx.cmd are associated with the xx.zip, so it's not recommended to manually do something to unzip it.
I suggest we can track the issue there(DC) and I will update the answer if there's any update or fix :)
I am trying to follow the tutorial from the command line. I have generated the project and deployed the blank website then added a vs2012 project to the source folder maintaining the original heirarchy. I have edited the docfx.json file to include "src/.csproj" "src/.cs*" which i assume are searched recursively. The project was previously commented for use with SandCastle so there should be plenty to extract or generate metadata from. I currently have vs2012 msdn installed. My issue is that the metadata never builds and even when I'm using the sample seed project all the md files show up on the webhost but not the documentation from the source files.
There is no requirement to have the complete VS2017 installed, instead you can just install the build tools of VS2017. Download
Just start a developer prompt for VS2017 environment and do docfx from there, it should then be able to extract metadata. I had problems with VB.NET projects with docfx and older Visual Studio tooling for some reason.
Is this possible?
We currently have build definitions and release definitions setup and working for Web Applications. However we have a lot of older web site type projects and will not work with the current build and release definitions that we already have setup.
Is there a way for us to get the web site projects to work with the build and release definitions in TFS?
Thanks
Recently changed my steps for the build definition and now that build is successful but the release still fails.
Build definition Steps are:
Nuget Installer, Copy Files, and Copy and Publish Build Artifacts
Release definition Steps are:
Powershell on Target Machines, and Windows Machine Files Copy
As web site projects needs bin folder and TFS doesn't want them to be stored in source, the best way to achieve is to convert web site projects to web application.
Best practice: Converting to web application:
https://msdn.microsoft.com/en-us/library/aa983476.aspx
But they made a workaround maybe you can try:
https://blogs.msdn.microsoft.com/tfssetup/2016/09/21/building-a-website-with-tfs-build/
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.
I have recently upgraded my .Net 3.5 solution containing some C# code projects and a ASP.net web site project to VS2010 (from VS2008). It is building and running fine inside VS, but I get some problems when trying to build it on my server with MSBuild 4.0 via TeamCity. It seems like the projects that are referenced from the web site are not built. This was all working fine before I upgraded to VS2010, MSbuild 4.0 and Windows SDK 7.1.
Inside the msbuild script that I use to build from teamcity I have defined project references for the web site like this:
<ProjectReference Include="..\src\trunk\DataAccess\DataAccess.csproj">
<Project>{C43242F4-7286-4BEC-9A27-001D6FC14860}</Project>
<Name>DataAccess</Name>
</ProjectReference>
When I try to run the build script I get an error message saying that it could not find the dll file when trying to copy it from the bin folder of the referenced project into the bin folder of the web site. This is happening because the referenced projects are in fact never built at all (No bin folder exists in the project dir).
Does anyone have a clue what may cause this? I am not very experienced with MSbuild, so I may have overlooked some important stuff. Is it not so that MSbuild will automatically try to build the referenced projects if no project output is existing?
Will be thankful for any help!
I would need some more info to guide you on this, but off the top of my head try adding
/toolsversion:3.5
to your msbuild call.
I found another post on this website describing your exact same problem. I also ran into this same problem too.
This blog on the MSDN Website describes the problem and the work-around. Basically it's a limitation of solution files which are not in an MSBuild format, but just a fancy text file. And the real thing is, that the dependencies need to be specified in the project files them selves not the solution file. ahhh... just read the link it explains it a hundred times better than my answer here.