We Keep Coding

How to copy project's resources folder to output directory in project with a reference to it

I have multiple projects in my solution. One of the projects has resources files (images). Then I have another project with unit tests. I'd like to have all these files available in unit tests project when the project with resources is referenced.
I've tried two solutions:
a) Apply a post-build script to the project with resources
The script copies resources directory content to the output (Debug/Release) directory as I need. But the script isn't executed when unit tests project is build (only when the project with resources is)
b) Set "Copy to Output Directory" property to value "Copy always" to all resources files
This works as I need even in project that has reference but I have to set this property manually to all the files. I wonder whether there is a way how to manage the same result but with a folder (to automatically copy all its content)
My question is: Is there any way how to automatically copy project's resources directory and its content to another project when the project with resources files is referenced?

You can check this link.
https://github.com/dotnet/project-system/issues/3203
As the link describes, if files are added to the directory during the build process, you must use a target to expand the wildcard, or it will only copy the files that existed at the start of the build.
You can use the following methods：
Open the *.vcxproj file and add the following code.
<ItemGroup>
<None Include="$(SolutionDir)config\**" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>
Hope it can help you.

Where do I put .less files in my Visual Studio Web Application?

I want to include a .less file in my Visual Studio Web Forms Application. I am running on the default template for VS 2015. Just wondering which folder to put the .less file in, and where I need to reference it (if at all). Currently all .css files are in the "Content" folder - should I just add it in there?
Please let me know if that's not enough information to go on.
Thanks!

for me and my team projects we use "Content" host sub folder for .less file and compiled CSS. when we compile .less file to CSS using gulp or grunt we output file to "CSS" or "Style" folder. you can create Grunt or gulp task to compiled file to CSS or style folder. this is npm package to compile less to CSS https://www.npmjs.com/package/gulp-less
>Content
---->/LESS
---->/CSS/Style

You will only need .less files when building your CSS. I would suggest a folder you don't plan on deploying to your website. You will only need to include the CSS files that are generated in your Content folder.
I've organized my directories as /Content for CSS and /src for any source files. When I publish to the website I only include the /Content folder. All references should be to the CSS file.
Root
/Content (CSS)
/src (less)

Cannot deploy website using "Precompile during publishing" option

I am trying to publish my web app.
Here is a picture of my setting for my publishing profile:
As you can see, I have the "Precompile during publishing" option checked.
Here is the Configuration settings for "Precompile during publish".
When this is checked, and I try and publish my web app, I get an error on one of my pages. When I hover over the tab to see the file location, the location is at: C:\Users\akemp.WT\AppData\Local\Temp\WebSitePublish... This is not the location of my source code, and if I make the changes on my local page, the site in the above given path does not get updated.
When I unchecked the "Precompile during publishing" option, my website published without any hassle.
What is going on here?

Pre-compilation means all your source code (including aspx.cs files for web site projects, class files under app_code folder, resx files, the global.asax file, and even the aspx files - unless "Allow precompiled site to be updatable" is selected) are combined and compiled into assemblies.
global.asax will have it's own assembly, app_code will have it's own, resx files wll be compiled in assemblies per folder, while the rest of the source code (aspx, aspx.cs) will be compiled into a single (and huge, depending on number of pages) assembly, and all will be in the bin folder of the web application as dll files.
If you do not pre-compile, these resources (aspx files for instance) will be compiled with the first request targeting that page.
This will enable you to make aspx and aspx.cs deployments without recycling the application.
And because a web site canot be both pre-compiled and compiled-on-demand, VS cannot run your published web site where your source code is located. But if you don't pre-compile, your source code can directly be served (since the first request will compile the resources and the compiled assemblies will go under C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files (or another explicitly set temp path for shadow assemblies)

When I tried publishing with the "Precompile during publishing" option checked, I got an error on one of my code behind files.
When I made changes to my code behind file in visual studio, saved and rebuild my solution, and then tried to publish, the issue would still exist. When I double clicked on the error in the Error list, it opened my page's code behind file, except for the fact that it was the file located at "C:\Users\akemp.WT\AppData\Local\Temp\WebSitePublish...\RandomPage.aspx.cs", and not located at my source folder.
After I individually published that page on it's own (Right click on RandomPage.aspx.cs, and select Publish RandomPage.aspx.cs), I was able to publish my web app with the "Precompile during publishing" option checked.

ASP.NET: Publishing Website doesn't publish Resources folder

I have a website that I'm developing with ASP.NET. I'm using Visual Studio 2015. When I right-click and hit publish website the site publishes correctly except that my resources folder gets left behind. Heres what the solution explorer looks like in Visual Studio
But after I publish it here are the files that get put on Azure (accessed via FileZilla)
How do I tell Visual Studio to publish the Resources folder with the rest of the website?

Likely Answer
Open the Solution Explorer.
Right click one of the files in the Resources directory.
Choose Properties.
You now need to set two properties.
Build Action Content
Copy to Output Directory Do not copy
Do this to all the files that you would like to publish as content to the web server.
File Properties for Web Server Content
Remarks on File Properties
The Build Action property indicates what Visual Studio does with a file when a build is executed. Build Action can have one of several values:
None. Not what you want. The file is not included in the project output group and is not compiled in the build process. An example is a text file that contains documentation, such as a Readme file, that you do not want to publish to the web server.
Compile. Not what you want. The file is compiled into the build output. This setting is used for code files. In other words, we compile the file and the stick it into the bin directory.
Content. This is what you want. The file is not compiled, but is included in the Content output group. For example, this setting is the default value for an .htm or other kind of Web file. The "Content output group" is a list of files that Visual Studio will publish while also maintaining the same directory structure.
Embedded Resource. Not what you want. This file is embedded in the main project build output as a DLL or executable. It is typically used for resource files. In other words, it not only goes into the bin directory but is also embedded within a .dll or .exe file.
Copy to Output Directory. This property specifies the conditions under which the selected source file will be copied to the output directory. The output directory is normally the bin.
See Also
What are the various "Build action" settings in Visual Studio project properties and what do they do?
File Properties on MSDN

If like me you are using Visual studio 2019, just right-click on the folder and select publish "name of the folder"

Steps to add resources to be published (Visual Studio 2017):
1) Right click the resources folder and select "Include In Project"
2) Now you should see Build Action: Content on the properties for the images.

Make sure the contents of your Resources folder have the proper "Copy to Output Directory" property. Right click the files you want to copy over, select Properties, then in the Advanced section look at the value under Copy to Output Directory. Generally this is set to "Do not copy" by default since most things get packaged up in the .dll. Change it to "Copy if newer" to get it to bring over the file. It'll bring over the folder structure as well.

Multiple .NET Configuration Files and Setup Project Problem

In order to handle settings for different deployment targets, I moved application settings from app.config to its own file and included that file in app.config via configSource. I also created a settings file for each target.Here is an illustration:
Project A
app.config (references settings.config)
settings.config
settings.Release.config
settings.Debug.config
During post-build, I copy the appropriate settings.{configuration}.config to the output directory. This is working fine so far and I can see settings.config file in the project output directory containing settings for the current build configuration: Release, Debug, etc.
However, I am having a problem with the setup project that I have for this project (Project A). Initially, it was not including settings.config file. So I set the build action for settings.config file as Content and I added content files from Project A to the setup project. This ensured that settings.config file was included in the setup. However, since the setup project appears to be picking settings.config file from the project directory instead of the output directory, settings.config file included in the setup is not what it should be. I want the one from the output directory to be included in the setup program since that one is the correct one for the current build configuration. I tried the following:
Added settings.config as a file to the setup project. However, it seems like I can only specify absolute path. So when I add it from the output directory of a particular build configuration (..bin\debug\settings.config), it does not work in other build configuration since (..bin\debug\settings.config) does exist in the directory specified. I looked into using relative paths or dynamic paths in the setup project where the build configuration could be specifed as part of the path but I could not find anything.
I considered using pre-build event to actually modify settings.config file in the project directory and then have it copied over the output directory by setting its 'Copy to Output Directory' to copy always or copy if newer. This should ensure that the appropriate settings.config is copied to the output directory just like the post-build based solution and should also ensure that the contents of settings.config file is updated before the setup project includes it. However, I don't like this solution because I would have to make sure settings.config file is writeable before I can make any changes since it is source controlled. If it is readonly, then I need to flip it to writeable, make changes, and then set it to readonly again. It is adding extra complexity.
I was wondering if anyone has a better idea or knows a setup project trick that allows me to include settings.config file appropriate for the current build configuration in the setup program.
Thanks

If I had to approach this problem, I'd start by asking the following question:
Why does settings.config have to be under source code control if settings.Debug.config or settings.Release.config provide the same information?
The answer, if I read your question correctly, is because you needed to force a settings.config file to appear as part of the build output. I'm guessing this is because your setup project is using the built in "Primary output" choice.
What you can do instead is add that file to your setup project as an explicit file reference. Right-click on the setup project and choose add / file, then select the file you want to include. As you'll notice (unless it's been fixed in VS2008 which sadly I'm not yet allowed to use at work), there is a very annoying limitation placed on manually added files - there is no way to make the path build configuration aware. You can work around that by copying the appropriate settings.config file to a common location (e.g. bin/Configuration) and picking it up from there. This does limit you to building Debug and Release versions sequentially, rather than in parallel, but for many this probably isn't a huge problem.
If you aren't required to use VS setup projects, I strongly encourage you to take a look at WiX (Windows Installer XML - see http://wix.sourceforge.net/ for more information). That will easily allow you to accomplish what is necessary, although if you are unfamiliar with the internal workings of Microsoft Installer the initial learning curve could be a little steep. Microsoft use WiX themselves for some pretty significant setup tasks (e.g. Office 2007, SQL Server, etc.). It had been hoped that WiX would become part of Visual Studio (for VS 2010), but sadly that is no longer the case.

I decided to go about achieving the same result (being able to have different configuration settings for different target environments) in a different way. So here is how I implemented it and it is working great. I read some of the posts here at SO about XmlMassUpdate task from MSBuild Community Tasks and decided to utilize it. Here is what I did:
1) For each project that needs to have different settings depending on the target environment, I added an xml file called app.config.substitutions.xml or web.config.substitutions.xml to the project. So, the project looked like
Project A
app.config
app.config.substitutions.xml
app.config.substitutions.xml file has the settings substitutions that XmlMassUpdate will process and apply to app.config file. Below is a sample substitution file that I use:
<configuration xmlns:xmu="urn:msbuildcommunitytasks-xmlmassupdate">
<substitutions>
<Development>
<appSettings>
<add xmu:key="key" key="SomeSetting" value="DevValue" />
</appSettings>
</Development>
<Test>
<appSettings>
<add xmu:key="key" key="SomeSetting" value="TestValue" />
</appSettings>
</Test>
<Release>
<appSettings>
<add xmu:key="key" key="SomeSetting" value="ReleaseValue" />
</appSettings>
</Release>
</substitutions>
</configuration>
For details on how to specify substitutions, take a look at the documentation for XmlMassUpdate or just do a search on it.
2) Now I need to run XmlMassUpdate as part of build automation (TeamBuild/MSBuild). So in BeforeCompile in TeamBuild build definition file (basically a proj file), I added the following to run XmlMassUpdate on config files that have a corresponding .substitution.xml file
<PropertyGroup>
<SubstitutionFileExtension>.substitutions.xml</SubstitutionFileExtension>
<TargetEnvironment>Test</TargetEnvironment>
</PropertyGroup>
<Target Name="BeforeCompile" Condition="'$(IsDesktopBuild)'!='true'">
<CreateItem Include="$(SolutionRoot)\**\app.config;$(SolutionRoot)\**\web.config">
<Output ItemName="ConfigurationFiles" TaskParameter="Include"/>
</CreateItem>
<CreateItem Include="#(ConfigurationFiles)" Condition="Exists('%(FullPath)$(SubstitutionFileExtension)')">
<Output ItemName="ConfigFilesWithSubstitutions" TaskParameter="Include"/>
</CreateItem>
<Message Text="Updating configuration files with deployment target specific settings..."/>
<XmlMassUpdate
ContentFile="%(ConfigFilesWithSubstitutions.FullPath)"
SubstitutionsFile="%(ConfigFilesWithSubstitutions.FullPath)$(SubstitutionFileExtension)"
ContentRoot="/configuration"
SubstitutionsRoot="/configuration/substitutions/$(TargetEnvironment)"/>
</Target>
Note that config files are read-only during the build, I make sure to set them writeable before running this task. I actually have another custom MSBuild task that runs before XmlMassUpdate that handles common settings throughout all of the config files such as connection strings. That task makes the config files writeable. I also don't check modified config files back to the source control. They're (appropriate config file for the deployment target) included in the installer.