I'm using VS2015, as I know I could add folder or files to Include In Project, but there's anyway to exclude from Project?
Currently, there's no way to exclude a folder from a Cordova project in Visual Studio. I'd suggest you add a vote for this feature on the Visual Studio UserVoice site (Mobile App Development category) if it would be useful to you.
A little late to the party, but I only recently needed the same thing. And I noticed that even in Visual Studio 2017 the option to exclude a folder or a file is still not given. But there are folders that are automatically excluded like "node_modules", so that means one way to achieve what you were looking for is project file hacking.
My requirements were only to exclude a folder, but I think you can apply the solution to files as well. Funny note: as you can see from the boiler plate project file, Microsoft intended for you to be able to exclude items, they just don't provide the option in the UI.
Unload your project file and right click "Edit [project name].jsproj"
Find the following section in the project file:
<PropertyGroup>
<!-- Customize which folders are not shown by default -->
<ExcludedItems>[boiler plate stuff ...];your_folder_here</ExcludedItems>
</PropertyGroup>
<ItemGroup>
<Content Include="**\**" Exclude="[boiler plate stuff ...];**\your_folder_here\**" />
</ItemGroup>
Add your folder or file at the location shown above
Save the file and Reload the project
Related
in the new asp.net 5 template there's a project.json in which you can exclude certain directories.
"exclude": [
"wwwroot",
"node_modules",
"bower_components",
"dist",
".tmp"
]
As you can see, I added a few folders like 'dist' and '.tmp', but they are still included in the solution explorer. There's not much documentation about this. How to exculde files/folders from your project in vs 2015?
The "exclude" property does not hide the folder from visual studio, it will not make the folder "disappear" from the solution explorer.
The "exclude" property removes the folder from the compilation search path. It is an instruction to the compiler (Roslyn) not the IDE. As a more comprehensive answer "project.json" is intentionally IDE agnostic. That is why there is both a projecname.xspoj and a project.json which both contain project configuration information. This is necessary to allow for more robust cross IDE and cross platform development.
You can verify this behavior yourself with a simple excercise.
Add a new class file (buildfail.cs) to your existing project (or
create a new project) in the root project folder.
Ensure buildfail.cs has the same namespace as the other source files in the
project, contains compilation errors, and is in the root directory.
You should see build errors in VS. If you don't manually build.
Create a new folder (excludeme) off the project root and move
buildfail.cs to that folder. You should still have build errors.
Add excludeme to the exclude property in project.json. The build errors should be removed because builfail.cs is no longer in the build search path.
You may be wondering what is VS using to know to hide the node_packages folder from the Solution Explorer display. I am unsure and it may not be user configurable but it isn' the exclude property. Comment out node_packages in project.json and you will get build errors (package restore failure) but the folder will still be hidden from Solution Explorer. Since this is IDE specific behavior one would assume that maybe it is defined in projectname.xproj but I found no such property so at this time it would appear to be black box magic by VS.
As of Asp.Net 5 beta-8 and complementary tooling update to Visual Studio 2015, you are now able to exclude/hide folders from being displayed in solution explorer. More information about this, and other changes are outlined in the announcement post. To hide a file or folder, right-click to bring up a context menu and select Hide from solution explorer. This creates an entry in the .xproj file:
<ItemGroup>
<DnxInvisibleContent Include="myhiddenfile.txt" />
</ItemGroup>
Note also that there has been a change to where bower packages are installed by default. Previously, the Asp.Net 5 templates in Visual Studio would install bower packages to a folder called bower_components, a practice familiar to web developers who do not use Visual Studio. However, apparently due to developer confusion, this has been changed to wwwroot/lib. This can be changed by editing the bowerrc file. As such, the bower_components folder does not exist in the new beta-8 templates. Please see this post by Scott Hanselman for more information.
It may not be ideal, but I was able to hide a folder from the solution explorer in an Asp.net 5 project by marking the folder as hidden in the windows explorer properties dialog. I had the .idea folder used by WebStorm showing up so it being hidden was not too big a deal. WebStorm doesn't mind.
It seems like the folder will not be hidden if it is already in the solution explorer. Mark it and it's contents hidden and move it temporarily out of the project folder. Make sure it disappears from the solution explorer before moving it back. It should not show back up. A restart of Visual Studio may also work, I didn't test that.
Rightly or wrongly, here's what I did to get bower_components and .sass-cache out of the way. In my case, node_modules was already excluded from my project somehow, even though it's at the same level with gruntfile.js. I still don't understand why it is treated differently. Anyone know?
First, I set my location like this in the .bowerrc file:
{
"directory": "../../artifacts/bower_components"
}
Then I adjusted my paths as necessary in my gruntfile.js
Also, To get the sass-cache folder out of the way, since I was using grunt-contrib-compass, I configured my compass task with this option:
cacheDir: '../../artifacts/.sass-cache',
There are other ways to do this if you are using other sass / compass tools.
RESULT:
I can now search my entire project for text and not get hits in my libraries.
bower_components and .sass-cache are out of reach of source control.
With the latest Visual Studio you just need to right-click the folder/file and chose "Hide from Solution Explorer".
That will change the "xproj" this way:
<ItemGroup>
<DnxInvisibleFolder Include="wwwroot\" />
</ItemGroup>
Looking at the state of asp.net 5 with visual studio 2015 I can only say that they made it much more difficult and inconvenient to work with task runners like gulp or grunt. Since I'm using Web API 2 to manage my data I switched to Visual Studio Code with bower, gulp and browsersync and this has proven a to be LOT easier and faster with much less clutter.
To make a startup template: https://github.com/Swiip/generator-gulp-angular
Now you can use any editor and you get a clear separation of front end and back end development. Plus you get to know gulp and bower and the (minimal) command line stuff which VS2015 tries to do for you (and fails to do so many times).
Oh yes: you don't have to exclude folders anymore, since the template has a much more sensible folder structure
I believe this question applies to CMSes in general.
I'm using a CMS, Kentico, for a particular web application. The CMS installer generates its own boilerplate project with 10,000+ files, and this project amounts to a runnable web app. Very few of the CMS-provided files are intended for modification. Yet standard practice is to add custom code to the project, and to check the entire project into source control.
I dislike the idea of checking in my entire CMS. I prefer my repository to contain only the code particular to the project, while vendor files are automatically "pulled in" from elsewhere. For example, Visual Studio can restore NuGet packages into a fixed location in the project, and this location can be ignored by version control.
In a way, development with the CMS is dirtier than when using a typical vendor library. Usually your own code depends on a library, while the library is independent from your code. However, the CMS wants to be your app, and your own code interweaves. The CMS requires customization of its own provided files. You can't just "pull in" the CMS files to a fixed location and then ignore that location.
Given this scenario, I'd still like to omit as many of the CMS files as possible. So far, I've settled on this strategy:
Keep a pristine, readonly copy of the CMS-provided files at a standard, local path.
Create a fresh project root directory.
Copy the CMS-provided project file to the project root.
In the copied project file, change the 10,000+ file paths to point to those pristine CMS files, which are external to the project root.
Place only files with custom code into the project root. If a CMS-provided file must be modified, copy it into the project root directory and use that copy.
This strategy sounds good in theory, but it's more complicated in practice. Here are a couple complications:
Changing 10,000+ file paths to "link" in external files turns out to be more than a find-replace operation. More complex mapping is necessary to preserve the pristine project's directory structure.
The web server requires all the files to be in the same directory. Using the project file to link in external files is fine for compilation, but you've split your web root in two.
For the latter problem, it seems the best workaround is to perform post-build copy operations. This is, in itself, more complex than it seems from the outset.
As I write this, I'm starting to feel like I should go ahead and just dump the entire working CMS into my repository. It feels dirty, but it's a hell of a lot simpler. Before I do that, does anyone have any experience or ideas for how I might accomplish my goal?
To restate my question: How can I exclude my CMS's provided files from my version control repository, while still including them both in my project / build script and in my web app root?
Here's another idea for how to accomplish this:
I establish a standard local directory for Kentico DLLs and the Kentico installer, which will not be in version control.
I create KenticoSupport.csproj, a class library of types extending built-in Kentico types, just as they are intended to be extended. This will also contain content, such as JS, CSS, ASPX, ASCX, etc. files. This will be in version control, but it references the central Kentico DLLs, which are not in version control.
I create KenticoBuilder.csproj, a mostly empty project that is mainly a build script. It also contains a few simple *.patch files to modify matching Kentico files, such as Web.config and Global.asax.cs. This is under version control.
Here's what the KenticoBuilder.csproj script does:
Build KenticoSupport.csproj.
Create an output directory that will serve as both a web root and a project directory.
Install / copy the pristine Kentico project files into the output directory.
Apply patches to matching Kentico files in the output directory (mainly to add config lines and custom bootstrapping).
Copy custom DLLs and content from KenticoSupport to matching locations in the output directory.
Build the project at the output directory.
It's complex, but I think it might just work. Thoughts, anyone?
Kentico should hopefully be fixing this soon, with pre-built dlls you can reference rather than rebuilding the entire CMS every time you modify C#.
Until then, have you considered using a Symbolic Links to reference your pristine files? Then just overriding the links with your modified files when need be?
See this other question if you haven't used them before. mklink comes with newer Windows versions (Command-line), but there are a bunch of third party GUI based apps as well.
I came up with an ideal strategy:
Place the pristine CMS files at an external "code libraries" location, and make them read-only for good measure.
Make a copy of the CMS-supplied project file.
Convert all project items to link to the code library's copy, including assembly references. The required link element for MSBuild complicates this, so I wrote a little console app to parse the XML and generate the necessary elements. I also store the path to the library in a property.
At this point, you have a compilable project. The files are all just links to read-only, baseline, CMS-provided files, but the IDE shows a nice directory structure, as if the files were actually in your repository. As you customize, you can replace the links with your own actual files.
However, your website files are now split between two completely different locations. The web server needs them to actually be in the same directory. This is where some scripting comes in handy.
Using your build scripting tool, plug into the post-build event to copy linked files into the project directory. Naturally, you can omit the compiled files. Here's how I did it with MSBuild (thanks to this blog post):
<Target Name="AfterBuild">
<ItemGroup>
<LinkedKenticoFiles Include="#(None);#(EmbeddedResource);#(Content)"
Condition="$([System.String]::new('%(FullPath)').StartsWith('$(MY_LIBRARY_BASE_PATH)'))" />
</ItemGroup>
<Copy SourceFiles="%(LinkedKenticoFiles.Identity)"
DestinationFiles="%(LinkedKenticoFiles.Link)"
SkipUnchangedFiles='true' />
</Target>
Optionally, plug into the cleaning event to remove those files. I used similar MSBuild syntax to delete the files, and because it leaves behind empty directories, I remove empty directories, too. (Thanks to this answer.)
<Target Name="BeforeClean">
<ItemGroup>
<LinkedKenticoFiles Include="#(None);#(EmbeddedResource);#(Content)"
Condition="$([System.String]::new('%(FullPath)').StartsWith('$(MY_LIBRARY_BASE_PATH)'))" />
</ItemGroup>
<Delete Files="%(LinkedKenticoFiles.Link)" />
<ItemGroup>
<Directories Include="$([System.IO.Directory]::GetDirectories($(MSBuildProjectDirectory), '*', System.IO.SearchOption.AllDirectories))" />
<Directories>
<Files>$([System.IO.Directory]::GetFiles("%(Directories.Identity)", "*", System.IO.SearchOption.AllDirectories).get_Length())</Files>
</Directories>
</ItemGroup>
<RemoveDir Directories="#(Directories)" Condition="%(Files)=='0'" />
</Target>
Optionally, make your source control ignore the site / project folder, to avoid checking in the temporary, copied site files.
I am using a regular Visual Studio Setup Project to deploy my ASP.NET application. I need to handle the case of an existing web.config existing in the target directory. When one is found, it needs to be renamed before the install takes place. If this does not happen, the new web.config will not overwrite the old.
How can I get my custom action to rename the old web.config BEFORE the files being installed are copied?
So far I have tried by deriving from System.Configuration.Install.Installer and overriding the OnBeforeInstall, Install and Commit. It seems that all of these methods take place after the new files are copied into the target directory.
I found solution my self.!
you have to edit WebDeploy project Right click and OpenProject File. and its Extension must be .wdproj.
Add these Property Group
<PropertyGroup>
<TransformWebConfigEnabled>False</TransformWebConfigEnabled> <AutoParameterizationWebConfigConnectionStrings>False</AutoParameterizationWebConfigConnectionStrings>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
</PropertyGroup>
And for more help you can follow link.
[1]: Can't rename MSI afterwards
and for Help:
[2]: https://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/
I am currently attempting to use Visual Studio 2010 'Publish' and MSDeploy functionality to handle my web deployment needs but have run into a roadblock with regards to customizing the package depending on my build configuration.
I develop in a 32bit environment but need to create a release package for a 64bit environment, so in the 'Release' configuration I have a post build event that copies the 64bit version of a third-party dll into the bin directory overwriting the 32bit version. When I use the 'Publish' functionality, even though the correct 64bit dll is being copied to the bin directory, it doesn't get included in the package.
Is there a way to get the 'Publish' to include files that have been copied into the bin directory during a post build event?
I answered a similar but different question at How do you include additional files using VS2010 web deployment packages?.
In your scenario you are using post build event, I would recommend dropping the post build event and implement your actions using your own MSBuild targets instead of post build event. Below you'll find the text of the other answer.
From: How do you include additional files using VS2010 web deployment packages?
Great question. I just posted a very detailed blog entry about this at Web Deployment Tool (MSDeploy) : Build Package including extra files or excluding specific files.
Here is the synopsis. After including files, I show how to exclude files as well.
Including Extra Files
Including extra files into the package is a bit harder but still no bigee if you are comfortable with MSBuild, and if you are not then read this. In order to do this we need to hook into the part of the process that collects the files for packaging. The target we need to extend is called CopyAllFilesToSingleFolder. This target has a dependency property, PipelinePreDeployCopyAllFilesToOneFolderDependsOn, that we can tap into and inject our own target. So we will create a target named CustomCollectFiles and inject that into the process. We achieve this with the following (remember after the import statement).
<PropertyGroup>
<CopyAllFilesToSingleFolderForPackageDependsOn>
CustomCollectFiles;
$(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForPackageDependsOn>
</PropertyGroup>
This will add our target to the process, now we need to define the target itself. Let’s assume that you have a folder named Extra Files that sits 1 level above your web project. You want to include all of those files. Here is the CustomCollectFiles target and we discuss after that.
<Target Name="CustomCollectFiles">
<ItemGroup>
<_CustomFiles Include="..\Extra Files\**\*" />
<FilesForPackagingFromProject Include="%(_CustomFiles.Identity)">
<DestinationRelativePath>Extra Files\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
</Target>
Here what I did was create the item _CustomFiles and in the Include attribute told it to pick up all the files in that folder and any folder underneath it. Then I use this item to populate the FilesForPackagingFromProject item. This is the item that MSDeploy actually uses to add extra files. Also notice that I declared the metadata DestinationRelativePath value. This will determine the relative path that it will be placed in the package. I used the statement Extra Files%(RecursiveDir)%(Filename)%(Extension) here. What that is saying is to place it in the same relative location in the package as it is under the Extra Files folder.
Excluding files
If you open the project file of a web application created with VS 2010 towards the bottom of it you will find a line with.
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
BTW you can open the project file inside of VS. Right click on the project pick Unload Project. Then right click on the unloaded project and select Edit Project.
This statement will include all the targets and tasks that we need. Most of our customizations should be after that import, if you are not sure put if after! So if you have files to exclude there is an item name, ExcludeFromPackageFiles, that can be used to do so. For example let’s say that you have file named Sample.Debug.js which included in your web application but you want that file to be excluded from the created packages. You can place the snippet below after that import statement.
<ItemGroup>
<ExcludeFromPackageFiles Include="Sample.Debug.xml">
<FromTarget>Project</FromTarget>
</ExcludeFromPackageFiles>
</ItemGroup>
By declaring populating this item the files will automatically be excluded. Note the usage of the FromTarget metadata here. I will not get into that here, but you should know to always specify that.
I found a workaround for the problem by using the ExcludeFilesFromDeployment element within the project file. I got the idea from Web Deployment: Excluding Files and Folders
So if you need to package project files as they exist in your project directory after a successful build and associated post build steps then do the following.
Edit "Package/Publish Web" project settings and
select Items to deploy to be "All files in this project folder"
Unload the project
Right click on the unloaded project and select to edit the project config
Locate the PropertyGroup element associated to the configuration setting e.g. "Release"
Within the PropertyGroup element add in the following elements and exclude files and folders you don't want in the package
<ExcludeFilesFromDeployment>*.cs;**\.svn\**\*.*;Web.*.config;*.csproj*</ExcludeFilesFromDeployment>
<ExcludeFoldersFromDeployment>.svn;Controllers;BootstrapperTasks;Properties</ExcludeFoldersFromDeployment>
Save and reload your project
This solves my problem for the time being but if there is a better solution then please let me know, as this is not ideal due to the hackery involved, but then again perhaps this is an uncommon deployment scenario?
Select your files or folders and Change Build action as Content from Properties Window.
I know its a old question but none of these worked for me .
In 2017 VS I just right clicked on the extra folder to be published and select publish it worked.
Example:
Adding the bin folder (and it's contents) to the project caused the files to be copied to the publish output directory.
For me, my issue was that I needed to place a proprietary software license file in the bin/ folder, but did not want to copy it manually each deployment.
This was using Visual Studio 2015 Professional
I know this is an old conversation but I came upon it while trying to do the same thing and I thought it would be helpful to add what I found here.
Nearly all the articles about including extra files in your publication use this method of adding the CopyAllFilesToSingleFolderForPackageDependsOn or CopyAllFilesToSingleFolderForMSDeployDependsOn items in the PropertyGroup and they all same something like "I added this to the end of the file ..."
This is what I did and spent an afternoon trying to find why nothing was happening until I realised there was already a PropertyGroup section at the top of the file. When I put my CopyAllFilesToSingleFolderForPackageDependsOn into that section it worked fine.
Hope this saves someone time some day
I have a web application project. I have DLLs that I reference in the project stored in my bin/ folder. Well, whenever I do a rebuild or clean from Visual Studio, it will delete everything in that folder. How do I prevent this from happening?
Do not put anything into bin yourself. bin is the target folder for binaries - it is not a source folder for binaries.
Create yourself a lib folder or something like that to put your third-party binaries into. You might even name it "Third Party Binaries", since not everyone knows that "lib" means the same thing. Make your references to the binaries in this folder, and Visual Studio will copy them into bin when necessary (including on a rebuild).
I'll stay away from asking the 'why' question and just state the how. Mark the files as read only and VS shouldn't delete them.
Follow John Saunders answer and put your .dll's into a separate folder. In my case I named this folder "ServerAssemblies". Then modify your project file (.csproj in my case) and add an "AfterRebuild" target.
<Target Name="AfterRebuild">
<ItemGroup>
<ExtraAssemblies Include="$(SolutionDir)ServerAssemblies\**\*.*"/>
</ItemGroup>
<Copy SourceFiles="#(ExtraAssemblies)" DestinationFolder="$(ProjectDir)bin\"></Copy>
</Target>
Can you explain why you have to store it in the bin folder to begin with? i always create a separate folder for example /components where i store all referenced dll's.
One thing the "don't do it that way!" people are forgetting is source control and 3rd party software. Using SVN you often get files that if physical references were used would create mismatches when they're not in the same physical location.
One CMS I'm working with at the moment prebuilds the VS project and solution when you set up another "instance" of it. It dumps in some dlls it needs... but if you rebuild they vanish.
The simple solution in both cases is to do as stated above and call it done.