I converted a VS2010 ASP.Net MVC3 project to VS2013 MVC4. Now when I publish, it is copying the contents of my project to the bin folder.
I can't understand what I did to make it do this..How do I fix it so it doesn't do it?
Your files are incorrectly set to copy to the output folder (\bin) during build. Make sure that the Copy To Output setting on each file is set to Do Not Copy.
Normally, you don't need to copy much of anything to your bin folder. When publishing, all of the content pages (*.aspx, *.html, *.css, etc) will get picked up by publish just by existing in the project. This is determined by the Build Action being set to Content. (Note: you can exclude files by setting the Build Action to None)
For code files, there's 2 ways it could go. in a Web Application project (which MVC is) most code files, such as controllers, models, or code behind files in WebForms, are compiled into your site's DLL already. These have Build Action = Compile, meaning they get compiled up front and don't need to be included in the publish. The exception to this is files in App_Code, which are deployed to your site (Build Action = Content) and compiled at runtime. You can also choose to pre-compile your site in the publish settings (Settings -> File Publish Options -> Precompile during publishing), which will process the App_Code files automatically (i.e. you can leave them as Build Action = Content and VS will compile them and publish the output instead).
Related
I'm developing an ASP.NET Core 1.0 application which I deploy to a Linux machine using Docker.
In my CI pipeline I'm publishing the project using dnu publish, then I build the docker image with docker build.
I have a static binary file that I need to use in my docker image. (It's a hotfix which I need to copy into the coreclr runtime directory.) I want to be able to access that file with a command from my Dockerfile.
What is the idiomatic, reliable way to make that file get copied into the output directory when I'm doing dnu publish? What I'm currently doing - because I couldn't find a better solution - is adding it to wwwroot, so it gets copied into wwwroot in the output folder.
However, I don't want that file to be publicly accessible, it would be much better to make it end up in approot.
The approaches I found on SO and tried, but are not working:
Including the file in the project.json as "contentFiles": [ "mylib.so" ]. If I do this, I get the following error during the dnx build:
Error: The process cannot access the file 'C:\myapp\src\myapp.web\mylib.so' because it is being used by another process.
I tried to experiment with creating a custom postBuild script (found the suggestion here: New .NET "project.json" project, copying pre-built native .dlls to the output directory), but I can't figure out where to copy the file, since I have different CI pipelines publishing the same project using different publish output directories, so I cannot hardcode the directory path into my project.json.
Or is there a way to copy it into the build directory, which will be picked up by dnu publish regardless of the output directory of publish?
I am trying to exclude certain files/folders from deployment of a web project in Visual Studio Online to an Azure website.
The web project has a Content folder with CSS, JS, build scripts and so on, which are only necessary for development, once deployed to Azure the CSS and JS is loaded from a CDN. Currently the build from VSO is copying all those files to the webroot in Azure, which is unnecessary and a potential security issue in case of the build scripts.
Now I know this can be prevented by setting the build action of a file to None, but this a very tedious solution because there is a lot of development going on, new files get added all the time and it is easy to forget this setting.
First I tried setting the Content folder to Cloaked in the build definitions source settings, but this only causes VSO to not download this folder on build, msbuild will still complain that those files are missing.
Is there a way to tell msbuild to ignore the whole Content folder? I already tried adding /p:ExcludeFoldersFromDeployment="Content" as a msbuild argument in the build definition, and also tried the solutions in here How to get Visual Studio 'Publish' functionality to include files from post build event?, but nothing is working.
I was studying msbuild log files and came up with a solution that is good enough for us to work with.
The first thing I learned was that I cannot prevent msbuild from copying files with build action Content to the output directory, at least not without changing the Microsoft.WebApplication.targets file, which I didn't want to do and am not even sure is possible with VSO build.
Anyway because of this we cannot set the source settings of our Content folder to Cloaked in the build definition, since this will cause the build to fail.
What we ended up doing was described in this answer: https://stackoverflow.com/a/3140349/1230302
So by adding the ExcludeFoldersFromDeployment statement to the .csproj file, the Content folder is excluded from the webroot.
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
<OutputPath>bin\</OutputPath>
<ExcludeFoldersFromDeployment>Content</ExcludeFoldersFromDeployment>
</PropertyGroup>
It is not an ideal solution, but at least this way nothing gets deployed if a developer forgets to set the build action to None.
The built in continuous delivery options are designed for convenience. Of you need something custom, like skipping deployment of files that have not changed, then you will need to write something yourself.
You can easily call PowerShell to complete any task from the build process.
If you'd like to customize your build as part of the VSO build system, you can just override your BuildTemplate.xaml file.
Visual Studio Build uses Windows Workflow (xaml) to make a workflow on what the build is supposed to do. You can edit this file and do any modifications to the directory structure before or after the build.
Here is an example.
I have an automated build process set up to run from a build definition in TFS, which publishes a web application and generates/executes a database project script successfully via publish profiles that are passed as msbuild arguments in the build process definition. Everything is now running as expected except that several unnecessary files are being deployed to the target folder, including the .csproj file, all of the config transforms, and the properties folder which contains all of my publish profiles.
This is strange because 1. It's definitely not including ALL files/folders and mostly appears to be including ones used by the publish profile like transforms, while applying the transform correctly and excluding any explicitly excluded file (as defined in the pubxml), and 2. The process works perfectly if I do it by publishing from the project in Visual Studio 2013. I have the profile configured to only include files needed by the application, and I've confirmed in the csproj file that this property is there.
I tried excluding the properties folder from deployment in the pubxml file, but this causes the build to crash because it can't find the assembly file. What I've gathered is that the process is keeping all files it needs to complete the build, and dropping all of those files in my destination folder. FWIW, I'm using the "file system" method and I'm not sure yet if web deploy will make a difference. I haven't been able yet to connect to the target server with web deploy, but that's a separate problem to solve. Is there something in the build that I can configure so that my destination folder has only the files it needs to run the application, and not the files needed to BUILD the application?
FYI I also have not been using a drop folder, I'm not sure if that makes a difference or not but that might be the only thing I haven't tested as it doesn't seem necessary since I'm using a publishprofile and don't want to use the default tfs build configuration.
I found a solution that works well enough, after reading this: http://www.asp.net/web-forms/tutorials/deployment/advanced-enterprise-web-deployment/excluding-files-and-folders-from-deployment
This was a little uglier solution than I wanted, since it requires hard-coding the names of excluded files, but it does the trick and only requires identifying the files and folders in one location instead of altering a publish profile for each target environment. I created a wpp.targets file and used the ExcludeFromPackageFolders and ExcludeFromPackageFiles elements to identify the extra files. Ironically, if I don't also name the wpp.targets file in the exclude element, THAT file is included in my package. It's possible MSDeploy doesn't have the same issues with TFS as filesystem, but after spending half a day trying to work through a different set of issues and permissions workarounds, we decided that file system is a cleaner publishing method.
I am newbie to TFS.
I am trying to automate process of build upon checking in the code in TFS.
I setup a Controller and an Agent. I created a new build definition and set a "build" and "drop" folder on c:.
I check in the code, expecting to see the generated dll files in "drop" folders. There's none, just "logs" folder. The "binaries" folder in "build" folder is also empty. Apparently the binaries are not being generated at all. How can I have MSBuild to generate the dll files?
They are generated when I compile the website locally on my development machine under "bin\" folder. The solution is comprised of two separate projects: "core" and "web" where "core" is referenced within "web".
Any thoughts?
What is the Summary showing of your build that ran? Or are there errors in your build? You can check the log of the build by opening the build in Visual Studio and then click View Log.
I have a Visual Studio 2010 solution that is set to build in Debug x86. Visual Studio therefore sets the output path to \bin\x86\Debug, which seems logical enough.
The solution contains about 50 projects; the start-up project is a WCF project.
When I do a build, I would expect all output dlls to go to \bin\x86\Debug, as that is what is set in the project settings. But weirdly, I see dlls being created in bin\x86\Debug and in \bin. Why would Visual Studio put any dll in \bin if the output path is not set to that directory? It seems that all dlls go to \bin\x86\Debug, and all dlls except for the start-up project go into \bin. Any idea why it would do that? (We have other solutions that don't use WCF, and they don't have this problem.)
The other annoyance is if I run the service from Visual Studio and then try to access my service in a web browser, by going to http://localhost:1240/MyService.svc, it doesn't work, because the start-up project dll is missing from /bin. I therefore have to manually copy this one dll from \bin\x86\Debug to \bin, so that all dlls are found and the service runs normally. (We could of course add a custom post-build step that does the copy, but you'd think there'd be a better way!)
To those of you working on WCF projects, do you leave the output path at \bin\x86\Debug? (Perhaps there is a way to configure the service, eg in the web.config or .svc file, so that it knows the binaries are in \bin\x86\Debug instead of \bin?) Or do you change the output path to \bin so that you can run your service straight from Visual Studio?
If you open the property page of you WCF Hosting project and goto tab Build, under the Output section of this tag there is a textbox that contains the location of the output binaries.
For a WCF project the binaries should go to bin directory irrespective of the build type (suc as Debug, Release). Make sure this value has been configured correctly.
The value needs to be configured for each build type\configuration.
If you need, for whatever reason, different outputs from different build configurations in different folders you could specify them like you did first and use a post build event command line that copies from your specified output folder to bin.
Like:
- untested code -
COPY/Y "$(OutDir)\*.*" "$(SolutionDir)$(ProjectName)\bin\"
- untested code -