I'm writing unit tests for an asp.net mvc project. I have a config file that I use in my tests, but for some reason, the config file has to be in in the bin folder in order to be found. Is there another way to do this as I don't feel it is best practice in having config files in the bin folder.
During compilation, your app.config file is copied automatically from the root directory to the bin folder. You shouldn't have to manually place an app.config file in the bin folder.
Assuming your project name is
MyTestProject
then after a build your bin should contain the following:
MyTestProject.dll
MyTestProject.dll.config
Plus any other referenced assemblies.
One interesting thing about this is that if, in Solution Explorer, you right click your app.config and go to properties (F4) you should see that the "Copy to Output Directory" option is set to "Do not copy". This is correct. The compiler should handle the copying and renaming. If you had the setting set to "Copy always", your bin would contain a file called app.config, which the runtime would ignore.
EDIT: If you are referencing other config files from within your app.config (or web.config for that matter) then these files will need to be deployed to the appropriate directory. An example of this might be a Spring.config file, referenced in the app.config:
<spring>
<context type="Spring.Context.Support.WebApplicationContext, Spring.Web">
<resource uri="~/Spring.config"/>
</context>
</spring>
Related
I am trying to publish a project in Visual Studio 2013 that has some files with very long names, including the path location. I moved the project to a location closer to my root C:\ drive, which allows it to compile, but when publishing, it tries to copy files to the %appdata% folder which results in a name over the limit.
Here is the error I get:
Error 10 Copying file node_modules\grunt-bower\node_modules\bower\node_modules\bower-registry-client\node_modules\bower-config\node_modules\optimist\node_modules\minimist\.travis.yml to C:\Users\jake\AppData\Local\Temp\WebSitePublish\WebProject--1320288221\obj\Debug\Package\PackageTmp\node_modules\grunt-bower\node_modules\bower\node_modules\bower-registry-client\node_modules\bower-config\node_modules\optimist\node_modules\minimist\.travis.yml failed. The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. 0 0 WebProject
Is there a way to either adjust this project's name or where it copies to temporarily so that I am able to publish from Visual Studio?
Citing #Britton from Temp path too long when publishing a web site project:
Add this to your publish profile to modify the temporary directory for
package/publish:
<AspnetCompileMergeIntermediateOutputPath>c:\shortPath\</AspnetCompileMergeIntermediateOutputPath>
Or according to Website publish failing due to file path being too long (citing #Jason Beck and #VeeKayBee):
Add the following line in default PropertyGroup of web project file:
<IntermediateOutputPath>..\Temp</IntermediateOutputPath>
In addition to Amnon Shochot's answer, above, I also had to apply Roland's answer from another thread.
My publish paths (in .pubxml) now look like this:
<publishUrl>c:\publish\proj\</publishUrl>
<IntermediateOutputPath>c:\publish\inter\</IntermediateOutputPath>
<_PackageTempDir>c:\publish\package</_PackageTempDir>
You have to be careful with this:
Important: If this option is set, be sure not to nest your temporary files inside the publishUrl directory, because it will wipe out the _PackageTempDir files, causing a failed publish, even if it appears successful.
I use the following script to deploy my ASP.NET MVC app to our web server:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe MySolution.sln^
/p:Configuration=TeamCity-Test^
/p:OutputPath=bin^
/p:DeployOnBuild=True^
/p:DeployTarget=MSDeployPublish^
/p:MsDeployServiceUrl=https://mywebserver.com:8172/msdeploy.axd^
/p:username=MyDomain\MyUser^
/p:password=MyPassword^
/p:AllowUntrustedCertificate=True^
/p:DeployIisAppPath=mywebsitename.com^
/p:MSDeployPublishMethod=WMSVC
Now I need to specify to not sync the /uploads folder. Can I specify that in this script? Thanks!
Clarification:
I have the Uploads folder in my project. I'd like for Web Deploy to create the folder. I do not want it to delete the folder/subfolders/files from my web server because it contains user-uploaded content.
Clarification #2:
I just found the SkipExtraFilesOnServer=True option. However, I don't want this to be global. I'd like to set it to a single folder.
UPDATE:
Apparently, what you really want is prevent web deploy from removing existing directory on the destination server, but still have the folder created in case it's not there. You can accomplish this as follows:
create YourWebProjectName.wpp.targets file next to you the project file with the following content:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<MsDeploySkipRules Include="SkipELMAHFolderFiles">
<SkipAction></SkipAction>
<ObjectName>filePath</ObjectName>
<AbsolutePath>$(_DestinationContentPath)\\NameOfYourFolder\\.*</AbsolutePath>
<Apply>Destination</Apply>
<XPath></XPath>
</MsDeploySkipRules>
<MsDeploySkipRules Include="SkipELMAHFolderChildFolders">
<SkipAction></SkipAction>
<ObjectName>dirPath</ObjectName>
<AbsolutePath>$(_DestinationContentPath)\\NameOfYourFolder\\.*\\*</AbsolutePath>
<Apply>Destination</Apply>
<XPath></XPath>
</MsDeploySkipRules>
</ItemGroup>
</Project>
Change NameOfYourFolder and YourWebProjectName accordingly. This assumes, you have it in the root, I believe, you can use relative path if it's not the case.
The first MsDeploySkipRules entry tells webdeploy not to remove any files in Name_OfYourFolder.
The second MsDeploySkipRules tells webdeploy not to remove any child folders in Name_OfYourFolder.
Also, to have the folder created if it's not present on the destination server, you have to do the following:
include the folder into the project
add a dummy DeployemntPlaceholder.txt file into it and include it into the project as well
DeployemntPlaceholder.txt is required to tell MSBUild to add the folder into the package: empty folders are ignored.
I've tested this approach and it works fine when you run publish in the manner you've shown. I've used this answer to get the msbuild items syntaxt right. I believe, this is a MSBuild way to customize flags, passed to webdeploy by MSBuild Deployment Pipeline.
If you ran MSDeploy directly, you could use skip arguments in the following manner:
-skip:objectname='filePath',absolutepath='logs\\.*\\someNameToExclude\.txt'
UPDATE 2
You might also want to have ACL write permissions set on your \Uploads folder - there's a complete guide to do this: Setting Folder Permissions On Web Publish
Conserning the original question "Specifying folders not to sync in Web Deploy", the easiest way to do this is as follows:
You can create a publish profile and add the following lines:
<PropertyGroup>
<ExcludeFilesFromDeployment>
File1.aspx;File2.aspx
</ExcludeFilesFromDeployment>
<ExcludeFoldersFromDeployment>
Folder1;Folder2
</ExcludeFoldersFromDeployment>
</PropertyGroup>
I've tested this approach for excluding files using publish profiles. An easy guide is here (scroll to Edit the .pubxml file to exclude robots.txt section).
You can also do this in .wpp.targets file or edit you csproj. See more information at Web Deployment FAQ for Visual Studio and ASP.NET
I have a file I need to have published with my ASP.NET site to the server. I put it in the project root and set 'Copy to Output Directory' to 'Copy if newer'. When I publish, it copies the file to a 'bin' sub-directory. No good! I need it at the root of the site. Other files (such as my *.aspx files) that are right next to it in my project get copied to the root. How do I set it so this file also get copied to the root?
Change the "Copy to Output Directory" to "Do Not Copy", then Set the Build Action to "Content". Copy to output directory copies the file to the bin folder. You would use that feature to copy a license file needed for the assemblies for example. Setting the build action to Content causes the file to be sent to the server in its relative place.
I have a web application project that references a third party assembly, which in turn uses some native dlls that it needs to find at runtime.
Because of that, I wanted to add these dlls to the bin folder of the project, so that they can definitely be found.
However, if I add the files to the project in /bin/, select "copy to output", the files are compiled and published into /bin/bin. Adding them to the root folder works, but can hardly be the right solution.
Adding them to the build target "AfterBuild" has no effect when publishing (e.g. "build deployment package")
It also has to work when building the solution via TFS, where the MSBuild target _CopyWebApplicationLegacy is invoked.
The solution was a combination of the things I had tried already:
Include the "Bin" folder in the project
Add the needed files (I added them as a link due to our development structure)
Set the following properties: "Build Action = Content" and "Copy to Output = Do Not Copy"
The files are now copied to the bin folder when publishing, even when automating the builds on TFS.
The component that needed this was GdPicture, which uses a couple of native DLLs during runtime.
It's common to have a lib folder in either your solution or workspace to put your third party dlls within. You would then add a reference to this location from your project and ensure this location is under source control.
You could also look at using NuGet to package this for you, which uses a solution level packages folder automatically.
Based on this article http://sedodream.com/2010/05/01/WebDeploymentToolMSDeployBuildPackageIncludingExtraFilesOrExcludingSpecificFiles.aspx. It's possible to define the msbuild target into main (lastest in order of solution's build) project file that will capture all files of the bin folder. Like this
<Target Name="CustomCollectFiles">
<ItemGroup>
<_CustomFiles Include="$(OutDir)\**\*" />
<FilesForPackagingFromProject Include="%(_CustomFiles.Identity)">
<DestinationRelativePath>$(OutDir)\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
</Target>
<PropertyGroup>
<CopyAllFilesToSingleFolderForPackageDependsOn>
CustomCollectFiles;
$(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForPackageDependsOn>
</PropertyGroup>
And place it before closing root project element.
Im trying to learn to make a web installer using Windows Installer XML (WIX 3.5). I found this blog about using msbuild in .wixproj files to avoid the scenario where the installer ends up dropping the web project assemblies right in the root of the app instead of keeping them in the bin folder like they're supposed to be.
Here is the link to that:
<http://www.paraesthesia.com/archive/2010/07/30/how-to-consume-msdeploy-staged-web-site-output-in-a.aspx>
But after adding the MSBuild scripts in the .wixproj file, I don't know what to do anymore. According to the instruction after adding the MSBuild script:
"When that target runs, you'll see a .wxs file pop out in the .wixproj project folder. Add the generated .wxs to your .wixproj project so it knows to include it in the build."
I really don7t know what this means. How can I run the target? I tried to build it but there was no .wxs file generated in the .wixproj folder.
Am I missing something? Please help...
Assuming you have added the section from the tutorial:
<Target Name="BeforeBuild">
...
</Target>
The target will be run automatically when you build the project. The "BeforeBuild" target is one of the standard entry-points to add your own modifications to the build. The target will then generate a file (named [WebProjectName].wxs that is placed in the same directory as your wixproj file. Click on the show all files button in visual studio and right-click on the file and "Include in project" That will then include the wxs is your installer and when you next build it will have the correct folder/file structure.