I run tests several times a day in Visual Studio 2012. I recently found that my disk space was very low. I found that the test results folder in my project was using 60 GB. I deleted the files, but I want to keep it from happening. I did a search for how to do this, but all I can find are solutions for 2008 and 2010. They stated I need to make some changes to the test tools in the options. I can't find this inside of my options. How can I keep from these files appearing, or keep them to a minimal?
Mark Seemann suggests extending the Clean target
Add this after the Import element at the end of the project file:
<PropertyGroup>
<TestResultsFolderPath>..\TestResults</TestResultsFolderPath>
</PropertyGroup>
<Target Name="AfterClean">
<RemoveDir Directories="$(TestResultsFolderPath)" Condition="Exists('$(TestResultsFolderPath)')" />
</Target>
Then whenever you want to manually remove the test results, you can just right-click in the Solution explorer and select Clean.
You can also achieve the same from the command line with the following
MSBuild /t:Clean MyProject.csproj
which can be scheduled if you want an automatic deletion once a week or whatever. As Mark points out, one nice feature of this approach is that you can control the deletion on a project by project basis.
Related
I am trying to track down a VS 2019 build issue for a few weeks which drives me crazy. I have a C# project (targeting .Net Framework 4.8) which VS rebuilds regularly even when nothing has changed. The project is not very complex and has no specific dependencies, but a postbuild event which must always be executed. Hence I used the approach described in this answer, which forces msbuild to do the "up-to-date" check instead of the VS IDE. This has worked well for years, but started to make trouble a few weeks ago.
To create a minimal reproducible example:
use the VS project wizard to create a trivial "hello world" console app, .Net Fw 4.8, AnyCpu
add the following lines to the csproj file:
<PropertyGroup>
<RunPostBuildEvent>Always</RunPostBuildEvent>
<PostBuildEvent>
</PostBuildEvent>
<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
</PropertyGroup>
change the "Run Post Build" setting in the IDE's project settings to "On Build Success" (or back to "Always", this does not really matter), save the settings
The Postbuild action is intentionally left empty, one can add arbitrary actions here, but even an empty action will produce the issue.
When I choose to rebuild the solution in the IDE (using Ctrl-Shift-B), without touching anything the source code, the executable is recreated. This effect occurs when the time between two consecutive builds is approx. 10 seconds or more, when I rebuild the solution quicker, the exe file stays untouched.
To make the effect more visible, I set "AssemblyVersion("1.0.0.*"), stripped the "AssemblyInformationalVersion" attribute from AssemblyInfo.cs, so the build system assigns a new build number to the exe file with each new creation, which allows to observe the effect in the Windows Explorer more easily (by activating the "File Version" column in the Explorer view).
Note this effect does not seem to occur when I comment out either the post build event, or the DisableFastUpToDateCheck setting.
I observed this with VS 2019 V16.11.9 and V16.11.10 (currently the latest versions in the "2019" product line).
In my real project, this happens for a central DLL inside a solution where more then 70 other projects depend on, including a large C++/CLI dll, resulting in a build time of ~2 minutes - every time I only want to start the debugger, since this causes a new build! And yes, I also tried to set the "project build output" settings to "Diagnostic", but could not find anything suspicious in the large amount of messages.
PostBuildEvent is problematic and 'old style' since it doesn't define its inputs and outputs. Because of that msbuild can't calculate whether it caused any files to change and thus forces a rebuild.
By replacing the postbuildevent with a custom target and by correctly specifying the inputs and outputs of the target, MSBuild can check whether any of the inpu ts have changed and whether the outputs are up to date to properly decide to skip the build altogether.
See:
https://learn.microsoft.com/en-us/visualstudio/msbuild/incremental-builds?view=vs-2022
PostBuildEvent is also no longer supported in new style SDK projects. Visual Studio will now automatically generate a new target when you setup a postbuild event in the UI.
Starting with jesshouwing's answer, and using this information from Microsoft how to extend the VS build process, I implemented this workaround: in the csproj, I added the following section the end:
<Target Name="CustomAfterBuild" AfterTargets="Build"
Inputs="... input for postbuild step ..."
Outputs=" ... output of postbuild step ..">
<Message Text="... some message here ..." />
<!-- here are the post build actions -->
</Target>
This seems to work well for now without the nasty effects. The only drawback here is that this custom build step does not show up in the Visual Studio project editor, but I can work with that.
When building my solution, the most recent (v6.2.1) RabbitMQ.Client.dll ends up here:
C:\inetpub\wwwroot\MyProject\RabbitMQ.Client.dll
I don't want that version. I referenced the latest RabbitMQ.Client.dll DLL in a project, by mistake, then undid that and referenced a previous version (v5.1.2), but the new one keeps showing up in wwwroot when building (we have a post-build event that publishes).
I cleared the NuGet cache, but it's still happening.
I searched for RabbitMQ.Client.dll in our solution folder and found these, all v6.2.1 (the new one, not what I want), in every one of our projects:
bin\Debug\netcoreapp2.2\publish\RabbitMQ.Client.dll
Is there a way to clear that folder? I'm guessing that's why the wrong version keeps ending up in wwwroot when building/publishing. Running Clean, in VS, doesn't do it.
Just add an automated MSBuild target to every your project's csproj file.
<Target Name="DeletePreviousPublish" BeforeTargets="_CheckForUnsupportedTargetFramework">
<RemoveDir Directories="$(PublishUrl.Remove($(PublishDir.LastIndexOf('\'))))"></RemoveDir>
</Target>
If your $(PublishDir) ends with \, you should use $(PublishDir.LastIndexOf('\'))) to make it as a folder so that RemoveDir will work.
If not, just use
<RemoveDir Directories="$(PublishDir)"></RemoveDir>.
And then, when you click Publish button, it will first remove the previous publish folder and generate the new one. It is automatic, so you no longer need to manually delete the folder.
Update 1
It is quite an issue and should be automatic to remove the previous and then use the latest used ones. From a purely vs usage point of view, this is an obvious issue. I have reported the issue on our DC Forum.
You can vote it and add any comments under the link if I did not describe the issue in detail. And hope the Team will fix the issue.
Since the process will take a long time and for now, you have to use my solution to get what you want.
I'm writing an application that will enable the creation of SQL files within visual studio. The user will enter commands via the Package Manager console which will generate sql scrips and deposit them in a specific directory within the Visual Studio Project.
The problem I have is that, when the files are generated, they are present on the file system, but not in Visual Studio. This is expected of course, as I need to then go and actively include the files within Solution explorer, but this isn't what I want. I want the files to "Magically" appear in solution explorer immediately after they're generated.
I've seen various solutions to similar problems mostly featuring amendments to the .csproj file such as this
<Compile Include="Sql\**\*.sql" />
but this isn't what i'm looking for. What i'm after is similar to how, for example, Entity Framework or MvcScaffolding work, where files / folders just magically drop into the project when commands run in PMC. I'm aware this runs off T4 templating, but that seems like too complex a solution for a simple issue like this.
I should qualify that there's no voodoo going on in the creation of the files, just plain old File.Create() stuff.
I'm open to any suggestions.
Thanks.
Check out this answer for a solution that worked for me. I have the same use-case where code outputs flat files and I need to include this output in the project.
At the end of your .csproj file add the following:
<Target Name="BeforeBuild">
<ItemGroup>
<Content Include="Sql\**\*.sql" />
</ItemGroup>
</Target>
IMHO, T4 is the way to go. You don't want to be bothering with older technologies for what you are trying to do.
Having said that, I wonder why is it required for the files to be added to the solution explorer? is it for source control purposes? (usually you don't want to source control auto generated files, you want to source control the original model).
Note that you could always click the 'show all' button and the files will appear in the solution explorer, without actually being a part of the solution.
I'm in the process of learning TFS2010 Team Build, Workflow and MSBuild. I've got a general understanding of Workflow and was recently able to do a successful test build.
Now I need some help with keeping build version and assembly versioning in sync. I've been reading several blogs by Jim Lamb and John Robbins on this subject however I'm feeling more confused now than when I started. Jim Lamb's blogs talk about using a custom activity which uses the current date to set the version number and John Robbins' blog talks about getting the last assembly version and doing everything in MSBuild since there are no extra dependencies.
Currently we are using a 4 place version number such as 3.8.0.2 then we increment the last number for each build. We use this version to synce all the assemblies. We would like to stay with this format and I'd like to handle all my versioning in workflow however I don't know how to read the last version from an assembly that way. I'm thinking this will require writing a custom activity but what method would I use to read last version?
Thanks in advance!
Jim
Stuart Preston explains a simple way to set the assembly info on his blog:
http://stuartpreston.net/blog/2010/05/02/simple-assembly-versioning-with-team-build-2010/
Edit:
Above link is dead, here is the cached version:
Posted by Stuart Preston on May 2, 2010 under Team Foundation Server
There are many more sophisticated ways of achieving this but none seemed to give me exactly what I wanted, so here I present yet another way of doing assembly versioning with Team Build 2010. I wanted my Team Build number to exactly match that of my assembly versions (and not be derived), like this:
(image)
So here’s how I do it. To start off with I customise the BuildNumber format within my build definition:
(image)
In my case, I decided to customize it so that the Major and Minor version numbers “0.1” were added explicitly. This lets me control the first two parts of the version number which is what I want to achieve. I also added the macros $(Month)$(DayOfMonth) with a 1 in front of it. For the 2nd May 2010 this would generate a number 10502. (The reason I don’t use the full year here is that for today it would generate a build number of 100502 and a file version number cannot be higher than 65335).
When I decide to work on version 0.2, 0.3 or 1.0 all I have to do is increment the Build Number here and save the definition, I’m also happy to increment the number when the year changes. I said it was simple!
The final part of the build number format was left as-is (i.e. the Revision number that increments by 1 with each build on that day and resets for the next day).
Now all we need to do is retrieve this version number when MSBuild is run against the solution, split the version number and take the numeric portion into the Properties\AssemblyVersion.cs file (you will need to comment out the AssemblyFileVersion line in that file first and check it in).
Here’s the fragment that you’ll need to insert in your .csproj file (you’ll have to check it out then open it in Notepad or your favourite text editor).
<UsingTask
TaskName="Microsoft.TeamFoundation.Build.Tasks.GetBuildProperties"
AssemblyFile="$(MSBuildProgramFiles32)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\Microsoft.TeamFoundation.Build.ProcessComponents.dll"
Condition="' $(BuildUri) '!=' '"/>
<Target Name="BeforeBuild" Condition="' $(BuildUri) '!=' '">
<GetBuildProperties TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)">
<Output TaskParameter="BuildNumber" PropertyName="BuildNumber" />
</GetBuildProperties>
<PropertyGroup>
<BuildNumberSplitLocation>$([MSBuild]::Add($(BuildNumber.LastIndexOf('_')),1))</BuildNumberSplitLocation>
</PropertyGroup>
<ItemGroup>
<AssemblyVersionLines Include="[assembly:AssemblyFileVersion("$(BuildNumber.Substring($(BuildNumberSplitLocation)))")]" />
</ItemGroup>
<Exec Command="attrib -r "$(ProjectDir)\Properties\AssemblyInfo.cs"" ContinueOnError="false" />
<Message Text="Lines being added: #(AssemblyVersionLines)" Importance="high" />
<WriteLinesToFile File="$(ProjectDir)\Properties\AssemblyInfo.cs" Lines="#(AssemblyVersionLines)" />
</Target>
(End of reference)
He modifies the csproj file to update the AssemblyInfo.cs file before build with values passed in by TFS so that the assembly is versioned according to a permutation of MMDDRev
Your situation is a bit different in that you'd like a custom build number. To do that, you could modify the BuildNumberFormat to be 3.8.0.$(Rev:.r). Since the revision is the only thing changing, TFS will automagically increment it for you.
If you ever want to update the 3.8.0. portion, you can again edit the Build Number Format manually. Otherwise you'll need a solution for storing & parsing the build number as part of the BeforeBuild task in your csproj.
I have finished my program in c#, hit build solution, and grabbed the exe out of the bin folder in my project directory. I noticed the description under the filename was "WindowsFormApplication1". I browsed briefly through any fields in the solutions explorer I might change, but nothing worked. Am I doing the right thing to release my program, and/or where can you change that description? I would like to just pass the exe around.
Two methods.
Right click on project=>properties=>Application=>Assembly Information...
Solution Explorer=>Project=>Properties folder=>AssemblyInfo.cs
You can change them in the project properties at Application -> Assembly Information....
If you're concerned about the meta data in general, you may want to disable the pdb at Build -> Advanced... -> Debug Info or the assembly will contain the full path to the .pdb file, wich usually contains the user name.
I'd like to add that in case you're working with multiple projects in one solution, one could create a separate build properties file. This way you don't need to set the properties per project.
Create the file Directory.Build.Props in the solution folder.
Add the following properties
<Project>
<PropertyGroup>
<Version>1.0.0.0<Version>
<AssemblyVersion>1.0.0.0</AssemblyVersion>
<FileVersion>1.0.0.0</FileVersion>
<Company>Stack Exchange Inc.</Company>
<Authors>Jeff Atwood, Joel Spolsky</Authors>
<Copyright>user contributions licensed under cc by-sa. rev 2020.10.26.37891</Copyright>
</PropertyGroup>
</Project>