I have a misunderstanding with MSBuild. I want to build a web application (with a traditional .csproj project file) and get the "entire output" of the build in a new, clean output folder - including all the website files that are included in the project with <Content Include="....
The AspNetCompiler utility makes this easy for "web site" style projects - you specify the input folder and the output folder, and they can be entirely different.
So far I've only had success specifying the OutoutPath folder, i.e. moving the bin folder - but this only gives me the binaries and ignores aspx, image files, etc.
I must be missing something obvious, or fundamental! Thanks indeed.
I finally found a couple of relatively obscure references to this issue on the web.
I found I could set the (apparently undocumented!) property WebProjectOutputDir along with the standard OutputPath property, like so:
<MSBuild
Projects="..."
Properties="WebProjectOutputDir=D:\Output;OutputPath=D:\Output\bin"
/>
I guess this property is used in Microsoft.WebApplication.targets or somewhere. If anyone could enlighten me further about this, I'd be very grateful!
Related
So I have an ASP.NET VB website that references several other projects (their DLLS are just put in the site's bin folder). I need to update a small piece of code in one of the projects, which I have done and it builds fine. However, when I copy over the new DLL to the website's bin folder it fails to build, and all the Imports statements say "BC40056: Namespace or type specified in the Imports xxx doesn't contain any public member or cannot be found", which results in a ton of errors like "is not defined" . There is no reference to the updated DLL in the website project's properties, but if I put the old version back it's all fine.
The project was copied from a server and the vbproj file contained references to other DLLs, but the HintPaths were a mixture of mapped drives and ..\..\..\. I've updated these so that they're all the full server location path, but this has made no difference. I tried adding the project to the same solution as the website and added a reference to the project instead, but this also made no difference.
I've done plenty of Googling but have yet to find a solution. Any help would be very welcome!
A few things
You don't want to just "place" the .dll's in the bin folder. One big reason is that when you do a "clean" project, the bin folder is deleted. So, anytime you do a clean project, what is in the bin folder is cleaned out. And a developer will often do a clean project if some kind of problem is occuring.
I would place those files in some folder in the project. (create a folder, or if its only one or two .dll's, then place them in the root of the project). At compile time, the .dll's will be copied to the bin folder. And if you using web deployment, then you can choose to have the .dll's all combined into one .dll. So, once again, you can see it makes little sense to place the .dll's in the bin folder, since during a build, they will not be required, and as noted, the resulting bin folder can and will as a "regular" development process be re-created (emptied out). I seen a good number of projects in which the developer did place the .dll in the bin folder (because they did not know where else to place the .dll's, and that was seemly the only place that the application worked. But, during a web build + deployment to the production server, those .dll's can be left behind - they not be copied to the final "deployment" build. (I'm basic saying don't do this!!).
You can also consider just creating folder called "packages" in the root. This is where all the nuget packages are placed. So, some folder for those .dll's is the idea here.
The other big issue? Well, just dropping some .dll's in some place does NOT give you the developer all the methods and properties of those .dll's when writing code (we are assuming these are managed code - not win x32 .dll's).
So, without adding a reference to that assembly, then I can't see how the project will even compile correctly, and how syntax checking, and general use of the assembly will ever work during the development process (so VERY perplexed that you don't have references to those .dll's - that as a general rule can't work).
Now, to use the assemblies? Yes, you want to add the .dll as a reference to the project.
So, in references, add the .dll as a reference.
And then in the property sheet for the refence? Make sure you have the "copy local" set = true.
eg this:
So, above is GhostScript.net reference. (a open source library to manipulate pdf's).
Note the long path name for the .dll location. But, MOST important is the copy local setting = true. This means during a compile and build (which as noted can clean out the bin folder), then the .dll will be output to the final build in the bin folder.
So, I can't see how you can compile anything without an actual reference to the .dll. That is quite much assumed and a given - else I see no way how your project can compile under any circumstances.
So, referance the .dll, and that should allow use of the class(s) and objects, and enable your code to compile. And make sure the copy local = true, as that is the process that will copy + place the .dll in the final output (bin) folder when you compile.
So it turns out that the project for the DLL I was trying to reference had the Target CPU set to x64. Changing this this to 'AnyCPU' then allowed me to reference it.
This post gave me the answer: Could not load file or assembly ... An attempt was made to load a program with an incorrect format (System.BadImageFormatException)
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 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 Sitecore/ASP.NET projects that I'm developing. Today at some point I inadvertently hit the "Clean" option in the solution context menu. It took me a while to figure out why my site was hopelessly broken. Turns out Visual Studio went ahead and deleted several required assemblies from the \bin dir which are not part of my project.
How can I prevent this from happening again?
The odd thing is that it did NOT delete everything... just a small handful. It left many that are not directly referenced by my project. This makes me wonder exactly what this feature is supposed to do? Is there some sort of file flag I can set? None of the files are set to read-only. If you're interested in details, the following got deleted:
Sitecore.Analytics.dll
Sitecore.Client.XML
Stimulsoft.Base.dll
Stimulsoft.Report.dll
Stimulsoft.Report.Web.dll
Stimulsoft.Report.WebDesign.dll
Telerik.Web.UI.dll
UPDATE: You know what... I guess what I'm really more interested in here is WHY Visual Studio is leaving most of the files and only deleting these specific ones.
The correct answer to your problem will depend on how you are referencing the assemblies and how you include them in your project output.
The bin and obj folders generated by a project are best considered "output" folders; these folders should only contain files produced by the project build.
When you perform a clean or rebuild of a project, all intermediary and compiled files are deleted from these folders.
You should be comfortable this is happening.
You should be able to restore these folders by running the build process at any time. If you have added files to these folders directly, it breaks the purpose of these folders and means you ought to rethink how you're adding those files.
The preferred way to reference compiled assemblies is to add them somewhere inside your source folders. From there, they can be added to a source control system as easily as any other file and can be referenced/copied by projects which depend on them. In my work, we have a "Libraries" folder which contains numerous third-party assemblies referenced by multiple projects in our solution hierarchy.
Try using a source tree like this and seeing if it works for you:
/Projects/My Solution/
/Projects/My Solution/Libraries/
/Projects/My Solution/Project A/
/Projects/My Solution/Project B/
We always add an AfterBuild event to the project file containing Sitecore.
<Target Name="AfterBuild">
<CreateItem Include="$(SolutionDir)\Third Party\Sitecore\*.*">
<Output TaskParameter="Include" ItemName="FilesToArchive" />
</CreateItem>
<Copy SourceFiles="#(FilesToArchive)" DestinationFolder="$(TargetDir)\%(FilesToArchive.RecursiveDir)" />
</Target>
Where the CreateItem Include is the path to where you have placed your Sitecore binaries.
Put the dlls in a different directory. You will probably not want them as part of the project. Reference the dlls from the new directory. When you compile the dlls will be copied to the bin directory.
I work with lots of projects and keep a bin directory at the root of my projects to store 3rd party dlls for exactly this reason.
Example directory structure:
MyProjects
- bin
- 3rdParty.dll
- Project1
- Project2
- ProjectN
This allows all the projects to have a well-known reference location for 3rd party dlls without having to copy the dll into each project.
If you are working on a team you should all agree on a standard directory structure for your code. This will save you lots of headaches beyond just this.
In case of Sitecore, just make sure to set the property of the reference(Sitecore.Kernel, Sitecore.Client, etc):
'Copy Local' = false.
I believe that if you put these files in a subdirectory other than bin, Visual Studio won't remove them. You can still make the new subdirectory part of your deployment.
Well, I'm going to go ahead and answer my own question, since it seems like the simplest answer so far. I marked the assemblies in question as Read-only. Now they don't get cleaned.
Still wondering why most of the others don't get deleted.