I have a WCF project with a single .svc file and some .config files in it. I'm trying to create a build definition in TFS 2010 that will copy these files to an IIS folder on another machine.
I've done similar things with other MVC projects using the CopyDirectory task in the build XAML template. In those, I copy from the _PublishedWebsites folder to the IIS folder. However, with the WCF project, there is no _PublishedWebsites folder.
So I tried updating the MSBuild script for the WCF project to create a _PublishedWebsites folder and copy the files to it. This works when I build locally in Visual Studio 2010. But when it runs on the TFS build server, it doesn't quite work.
What I see there is that in "C:\Builds\1\PROJECT\PROJECT (Continuous Build)\Sources\PROJECT\bin\_PublishedWebsites", I can see all the files.
I'm guessing this "1 folder" is a temporary folder used for building...? I'm not sure what it's used for. But when I look at the actual drop location for the build, in "C:\Builds\PROJECT (Continuous Build)\PROJECT_BUILDNUMBER\", I see nothing except log files. None of the files from the "1 folder" are there.
Note that this same solution also has a WiX project to create a deployment package. That seems to build fine, and shows up in the drop location with no issue.
"1 folder" is a temporary folder used for building
Yes. "1" is number of build agent(service that actually executes builds activities) on your build machine.
But when I look at the actual drop location for the build, in "C:\Builds\PROJECT (Continuous Build)\PROJECT_BUILDNUMBER\", I see nothing except log files.
- Usually "Copy Files To Drop Location" flag is responsible for that.
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 have a WebAPI project in Visual Studio 2013. If I build the project in Visual Studio, in the bin/ directory I see a file called MyProject.dll.config, which represents the web.config file at build time.
However, if I execute MSBuild from the command line, the .config file is missing, but all other files are present.
> msbuild.exe /t:build /v:q /p:Configuration=Debug /nologo \
D:\Workspace\MyProject\src\MyProject.sln
What gives? Why isn't the .config copied?
For deploying a web project or a web api project, the fact that there's no $(TargetName)$(TargetExt).config isn't a big deal. At run-time, IIS will use Web.config to figure out everything it needs for your assembly.
BUT!
If you're using a Web App or Web Api project as the basis for testing* then you can hit some snags. In particular, when it comes to assembly binding redirects (as is the case with something within the bowels of MVC which still relies on Newtonsoft.Json 4.5.0 when the current version at time of writing is 7.0.0). A colleague had a similar issue with another assembly his test project was depending on.
Now when you run your tests through Visual Studio (eg, via Resharper), they all work just fine. However, when your tests get to the CI server and they are run by nunit-console, you'll see assembly load errors. Not pretty. This is because of the described behaviour where VS is sneakily copying the .config file to the correct output and msbuild isn't. However, you can work around this with a post-build build event:
copy $(ProjectDir)Web.Config $(TargetDir)$(TargetName)$(TargetExt).config
This has resolved my issues with redirects. I hope it helps someone else.
You may ask "Why use a Web App or Web API project as your test project?". A Web* project is a lot more comfortable to deal with as a base for a test project which deals with .net assemblies and JavaScript tests as JavaScript is properly recognised (syntax highlighting) and there's a Scripts folder which has the quick "Add -> Javascript File" menu item for itself and descendant folders, so I prefer to use this instead of a plain Class Library project.
When I create a WebAPI project the web.config Copy to Output Directory is set to Do Not Copy by default. Did you select the Web.config in Solution Explorer and set this to a copy action?
I'm at a loss to explain why it seems to copy for you with the IDE build but NOT the msbuild cmd you show, this is not the behavior I see with a fresh WebAPI project in 2013.
We have some assemblies that are not referenced by our solution directly but are required for other libraries we are using.
I noticed in VS 2010 you can add a deployable assemblies folder and that would cause the files in it to get copied to the bin while building, it seems this was removed in 2012 as all of the Microsoft stuff is available in nuget now.
What is the best way to achieve this same effect, can I just add a folder to my project and add an after build copy task to copy all of that into the bin or is there a better way to go about this.
Currently the dlls are sitting in the project root and have their build action set to content which I gather makes them get copied to the bin, however I'd like to make it a bit simpler and not have to rely on having to set things as content.
What you're doing already isn't a terrible way of handling things, to be honest, and the way we've always done so here in my day job is simply to add the assemblies into our solution as references; that does mean that they pollute Intellisense, however.
Alternatively, Phil Haack blogged that you can create a folder called _bin_deployableAssemblies and put your files in there; Visual Studio 2010 will automagically copy those into your bin folder as a part of its default build action.
This doesn't work with TFS msbuild scripts, apparently, so The Dev Stop guys blogged about how to get that to work with TFS, using a customised Target in your msbuild script.
If _bin_deployableAssemblies is no longer working in Visual Studio 2012, I would guess you could add a build action to your project file, based on the TFS build action from The Dev Stop?
I have an issue. We are upgrading to VS 2012 at work. When we open a VS 2010 project Visual Studio converts the project. This is fine, because VS 2010 can still use the project (yay microsoft). However, there is a \Backup folder created in the solution directory. Is this being created as part of the migration? Is there any way to control it?
The reason I ask is that the process that makes this folder copies web.config files into the folder. If you then try to build the solution (these are MVC projects), we get a "It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS." error. The cause is that there is a web.config file in a subfolder instead of the root folder. We did not make and do not want this change, and cannot figure out how to control it. Deleting the Backup\Web.config file fixes the error. Renaming it from web.config to web.config.bak fixes the problem.
I don't really want to have to personally open and convert every single project, and don't want random people bumping into this problem. Any idea how to either stop VS from creating the Backup folder, or how to make it create them in the my documents studio folder etc? I can't find any setting to control this and can't find any good info.
By chance, are you using the MvcBuildViews property to pre-compile your views at build time? If so, this is why you're encountering this (since it does the pre-compile in the same directory, it doesn't filter out any of the files below the project directory).
Note that you will also encounter this issue if you use the Publish feature for this project. Publish copies the web.config under your intermediate build output directory (by default, obj/) before and after applying web.config transforms.
The good news is that in VS2012, or in VS2010 with the latest Azure SDK installed, pre-compile is now supported for Web Application Projects (including MVC). These settings are currently in the project properties, under the Package/Publish Web tab.
(this doesn't directly address your question about the Backup folder, but it was too long for a comment.)
There is no way to control it that I found. We had to go ahead and run through and convert every project to 2012 and delete the backup folders to prevent any other team from running into it.
In my web project I often have a number of files in my app_data folder. These files can vary from time to time (example translation files get a new language, lucene index gets updated and gets a new file name etc).
Visual studio only adds files to the deployment process if the files are seperately added to the project. So if a file has been added on disk, but not in the project, this file will not be copied to the server...
Is there a way to make VS add all files in a folder to the deployment process without me having to update it manually?
You can use a post build event to copy the contents of a folder to the build target.
This should get you started:
http://visualstudiohacks.com/general/customize-your-project-build-process/
Wow I just saw this was asked in 2009...I hope you figured this out already :)