So I have a web project that minifies and condenses our javascript to a couple of files as a post build action. The problem is that in order to build the project correctly I have to check out the target files because otherwise the build fails because VS doesn't have write access to these files. Is there anyway to include these files in TFS but not require file locking for them? I've done something similar to this with SVN but I've been unable to find a way to do it in TFS.
Related
We are experiencing bad slowdowns in Visual Studio 2019 that appears partly due to a large folder of content (~12,000 files) that we have in our wwwroot folder. This content rarely changes, but it ends up getting searched when we do "Find in files...", etc. which we don't need, and ends up slowing down normal operations such as adding/renaming classes.
Is there any way to keep the content in source control, exclude it from Visual Studio, yet still have it get deployed when we publish?
I haven't been able to figure out if this is possibly editing the csproj file using the settings such as DefaultItemExcludes, or various options on the ItemGroup element.
Here is what we have done to (hopefully) resolve this issue for us:
Added the following line to our WebApp.csproj file within the PropertyGroup:
<ProjectGroup>
<DefaultItemExcludes>$(DefaultItemExcludes);wwwroot\hugecontentfolder\**</DefaultItemExcludes>
</ProjectGroup>
The huge content folder stays where it is in source control, this simplifies things as we need those files there to be served locally for development
We updated our Azure DevOps pipelines with new tasks to copy the contents of that folder from source control into the build artifact staging directory
Updated the Dotnet Publish Azure Devops task to no longer zip it's output
Another new Azure DevOps task to Archive the build artifact staging directory (which now has the non-zipped dotnet publish output, as well as the huge content folder output in the correct location) into a zip file for publishing.
I am using Team Foundation Server 2013 and have the nightly build configured to deploy a web application. The web application is making use of the web API help pages which depend on the built in XML documentation files.
I currently have these XML files being output to the App_Data folder. These are not being copied to the server during deployment. I tried checking in the documentation files but when the build process tried to regenerate them it caused an access error as the files are read-only.
I currently have a placeholder text file inside the App_Data folder included in the project to ensure that the folder gets created but I have to manually copy across the documentation files in order for the help pages to work as intended.
What is the correct/best way of forcing these files to be copied?
Thanks
Ensure the project build order has the docs being built first. Right click on the solution and choose Project Build Order
Then add some MSBuild logic in your pubxml or wpp.targets file to add the generated help files to the FilesForPackagingFromProject ItemGroup.
http://sedodream.com/2012/10/09/VSWebPublishHowToIncludeFilesOutsideOfTheProjectToBePublished.aspx
Open the solution, right click on the .xml file, click Properties, for 'Copy to Output Directory' select 'Copy Always'.
I'm getting this error when building my Multi-Device Hybrid App.
EXEC : error : EBUSY, resource busy or locked 'C:\path\to\project\bld\Debug\www\.svn\wc.db'
Suspected cause:
From what I can gather, when the Multi-Device Hybrid Apps Visual Studio extension builds the app it seems to grab all files in the project directory (except for some specific files/folders e.g. bld/bin directories and the .jsproj file) and add them to the package. That's ok, but not ideal, it really should only be grabbing the files in the VS project. The problem I'm experiencing is becuase it's grabbing my SVN .db file and adding it to the package, TortoiseSVN status cache then picks up this file and locks it - resulting in my error.
This is my specific issue, but I believe others could experience similar issues if they have any other files in the directory that they don't want included in the app bundle. I'd suggest it could be fixed by somehow setting excluded files/folders from the build or by the build script not grabbing everything, only those files included in the visual studio project. I'm not sure how to request that, so hopefully the developers will see this post...
So, my question is: Does anyone know of any way to tell the Multi-Device Hybrid Apps Visual Studio extension build process (or vs-mda\vs-cli) to ignore certain files or folders?
Or, does anyone have any suggestions as to how to make SVN and this VS extension play nice?
Unfortunately Visual Studio includes all the files under project directory except bin\bld folder. Currently only simple workaround would be to keep the files which you want to be excluded from package outside project directory. You can add the file to solution explorer by using Add --> Existing Item --> Add as link in case you want the file to appear in solution explorer but not included for build or packaging.
it seems folder with test as its name will be considered differently, and it will be excluded from package.
Is it possible to copy checked in files to a specific folder using a build definition or script? For example, if a check-in a file that is in a folder in TFS, on check-in can I copy that file to a server that has the same folder structure?
TFS
$/Website/files/index.html
Copy To
\ws-file01-dv\files\index.html
You could easily setup a TFS Build that is triggered on Check-In (CI Build) that simply does a Get Latest then copies the source to a file share.
You would have to modify the DefaultTemplate.xaml, by default it already downloads the source to the Build Agent Working Directory, you just need to add a Copy Folder activity that copies it to the target file share. If you've never customized a build workflow before I recommend reading the ALM Rangers Guidance to learn how: http://vsarbuildguide.codeplex.com/
I have a custom MSBuild script (e.g. WpfResources.proj), in which I scan through multiple folders for *.resx files anc build .NET satellite resource dlls using the AL task. The output of this WpfResources.proj contain multiple *.resources.dll under different folders (corresponding to different projects which will need these resource dlls).
The example output folder structure is shown as following:
WpfResources
Bin
Project1
zh-CN
Project1.resources.dll
es-ES
Project1.resources.dll
...
Project2
zh-CN
Project2.resources.dll
es-ES
Project2.resources.dll
...
This WpfResources.proj can be built correctly by MSBuild.exe. However if I run it in TFS 2010 build (i.e. create a build definition and refers to the WpfResources.proj to build), it failed to copy all those resource dlls into the drop location. Actually it outputs nothing to the drop location even though on the actual build PC, the output is fine.
How can TFS 2010 build handle custom MSBuild scripts which output multiple files under multiple folders? Is there something missing in my WpfResources.proj which the Team build will consider as outputs of this MSBuild project?
On a build system, TFS handles the binary output directory and the copying of its output to a drop folder a bit special. It generates a central output directory for all output files.
I would imagine that your MSBuild project does output the standard way as if it were on a development system, with output bins under the project folder structure. TFS will not copy them to the drop folder, because by default, it only copies the binaries it produced under the central output folder.
For our systems, we solved the issue (that also goes for building VS Setup projects) but having a manual copy action embedded in the build template that copies the MSBuild output to either the centralized bin output folder, or directly towards the drop folder location.
For adding such a custom action, please see the fine TFS2010 customization blog of Ewald Hofman at: http://www.ewaldhofman.nl/post/2010/04/29/Customize-Team-Build-2010-e28093-Part-4-Create-your-own-activity.aspx.
Hope that helps.