I have a C# WinForms project, which I am working on in Visual Studio 2017 (although it was originally created in the 2015 version).
I don't recall having done anything special, but it has added a file called .dtbcache, that it wants to add to git. The file has no extension, and a Google search doesn't show any results.
The file is located in ..\repos\myprject\.vs\MyProject\DesignTimeBuild. Which means that the "dtb" part of the file name probably means design time build, but that doesn't really make it that much better.
Can I delete it or add it to .gitignore? I would prefer not to include it in our git repository, unless it is required.
Short answer: You can safely exclude it from your Git repo.
Long answer:
You're right that dtb stands for Design Time Build. This is a file automatically created by VS2017, with a bit more information here and here (links to a blog from someone working on the Visual Studio project system). In summary, it's Visual Studio more or less extrapolating what files will be produced in order to make sure Intellisense is fully available as intended.
From the linked articles, one of the purposes of this is to make sure Visual Studio has an answer in certain cases:
Given an assembly reference in the project file, what assembly on disk is that reference going to actually refer to at compile time?
Given a XAML file, what is the code that is going to be generated by the XAML compiler at compile time going to look like?
Given a glob file pattern (*.cs), what files are actually going to be included at compile time?
So the files, being generated on the fly, are not needed in your Git repo, and can safely be excluded. Moreover, from what I can tell, these files are specifically made and used by Visual Studio 2017.
Related
I am writing the code with my team by usin0 the Bitbucket service. The problem is the following:
Since yesterday, when I downloaded the last commit from our public repository I see all projects (folders) but in visual studio where I want to run the application the compiler tells me that some libraries, projects or references are missing. At the same time I see only one of four projects in visual studio(while it must be four). I've tried to rebuild the solution but this does not help.
When I asked one of my colleagues about the problem, he told me that this is a standard procedure and he will give me the access to all libraries and projects when the work will be finished.
My question is: Can I do something to got the access to all missing files?
P.S. I am the owner of Bitbucket repository
Check with your colleague their solution build before pushing new changes and all the dependencies / changes to packages.config and project files are pushed in.
Usually a clean and rebuild and a compare between project files will tell you what are the differences.
P.S. if you have a .gitignore file check that too, in case someone added something that is required to your project.
Visual Studio has a "Refactor Rename" feature where I can right-click any type or member and rename it, and it will update all references within a project or solution to match. Is this functionality accessible from MSBuild command line tools, without having to open Visual Studio?
(I'm doing this because I have a project that is so large that Visual Studio runs out of memory while attempting to calculate where the rename is needed).
As far as I'm aware that's not something that's available outside of Visual Studio; although you probably have a couple of avenues available for getting it done.
The first thing that I'd try is using a lighter editor, VSCode, Atom, etc. Something that uses less memory, but will still hopefully let you get the rename done. You might have to use a regex find/replace to get it done; whether that's an option kind of comes down to if you can make an accurate regex.
If you can actually get the project open in VS with no (or less, at least) problems, then you could also start unloading projects that aren't relevant to the rename. If you know that it's only available in certain projects then unload everything else, perform your rename, and reload the projects. If it's everywhere then you might still be able to do something similar to this, perform the rename in a few projects, unload them, load the next few, rename, etc. Although I'm honestly not 100% sure that'll work, I've never attempted it.
Regardless of what you try, if you haven't already be sure to have your code in source control just in case. I'm sure this is doable, but maybe not via the VS command line.
No. There is no shipping msbuild target, task or tool to rename variables from the command line.
You could of course write yourself. :)
But I highly suggest using Visual Studio Code as an alternative to Visual Studio for loading large numbers of projects. It's an outstanding cross platform IDE. And who knows, perhaps someone wrote a plugin for it to rename variables...??
When I create C# project in Visual Studio 2010, file Microsoft.CSharp.targets is included.
Is any documentation available for it?
Which targets in it, which properties are used?
It is especially useful when editing build script manually without VS.
The file with targets could be investigated manually (what I do from time to time).
But in such case it is not clear what is a matter of changes, what is by specification and what is no.
Everytime I need something about Microsoft.CSharp.targets I found it in different places.
I have not found "one place" with all described.
Does complete reference available?
Thanks.
No specific documentation I know of, it is an implementation detail for C# projects. You can find plenty of documentation about MSBuild in the MSDN library, the Microsoft.CSharp.targets file just contains targets that are specific to building a C# project.
The most important targets it implements are Build, Clean and Rebuild. They directly correspond to the commands you find in the VS build menu. The .csproj file merely sets properties that affect the outcome of the general targets. All of this is readily available on your machine, you can look at .targets files with an editor. There's just a whole lot of it and it is isn't exactly that easy to read, the concept of XML as a programming language is a bit, well, flawed. No debugger either.
I am building a C# solution in Visual Studio 2008 that has several projects and project dependencies. I am looking for a way to change dll version numbers ONLY when the code that builds the project changes. I currently use Beyond Compare to compare my locally built version to the production file system. The goal is to ONLY deploy updated dlls. I am using autoincrementing version numbers, and each time you open visual studio and do a build, all dll version numbers increment. The same goes for a full solution rebuild and when a different developer does a build and tries to deploy. Is there a way that i can configure Visual Studio to ONLY increment the build number based on changed file contents? Is there an add in that will do this?It seems a binary comparison of these files will also fail because of the different version numbers within the dlls. Does anyone know of a better tool compare only the contents of dlls?Thanks in advance.
One option is to move to a continuous integration solution such as Cruise Control .Net this allows builds to be triggered on check in to a source control system.
Regarding assembly versioning what I usually do is create a single SolutionVersion.cs (to replace the default assembly version cs) that is linked to each project (use the add existing item but change the button to add as link)
Then I use a NAnt or MSBuild task to take the cruise control build label number and overwrite the SolutionVersion.cs verison numbers before the solution gets built
That way I can take an assembly and trace it back to the code via CruiseControl build version (even better I usually get CC.net to label the source with the same number in source control)
Its not quite what you are asking, but I found this helpful in dealing with large solutions: Versioning Controlled Build. According to its doc it detects the changes you are interested in :
"If there is a file with a more recent timestamp (which means that the source code has been modified after the previous version change), the project will be marked for version update."
The recommended, supportable solution would be for your project to NOT auto-increment the build number using the visual studio way. Then you would need to manually, or write a pre-build script/ MS Build Task to do the increment.
There is an interesting sample in this codeproject article which you should check it out... it involves a prebuild task which does the task of updating the build number based on the day of the year
I would suggest that you look into options that your revision control system provides to embed revision information into source files. I've had enough problems with auto-increment in the past that I promised myself never again. These days I prefer something a little more concrete than a build number though and embed unique identifiers into every product of the build system.
I describe my own system in Embedding mercurial revision information in Visual Studio c# projects automatically. While my solution probably isn't right for you, there were other interesting options suggested in response to my question, so some of the solutions I rejected may, nevertheless, be useful to you, even if you have to adapt them to whatever VCS you use.
I've got a bit of a problem. I'm moving my source repository from one machine to another, and in the process I'm doing some culling of what's stored as I've learned more about creating/managing a repository since I started.
The problem is that we're using dxperience tools from devexpress and it uses the .net license system (licenses.licx). Originally I had this license in the repository, and I'm hearing that this isn't necessarily the best idea. So I haven't included it in the repository. But now, when I checkout the project from the repository on my machine (same machine that I was checking out to before the move), it's looking for the license file and not generating it as (I think) it should be.
We have run into the same problem using Infragistics controls.
Our solution has been to keep a blank licnenses.licx file in our source repository (Source Gear Vault) and then change the properties of the file to Read Only false on our local workations. This way we do not end up stepping on each other with that file and it is generated with the proper keys off of our workstations.
Of course this is a bit of a manual work around that may not be suitable for you, but that is how we have been doing it.
Alternatively, you can install the EmptyLicensesLicx nuget package, and it will make sure there's an empty Licenses.licx in your project, before it gets compiled (which is all you need).
This file should be compiled into your deployment assemblies automatically by having licenses.licx included as an embedded resource. Under the hood, Visual studio uses lc.exe to include this in your assemblies.
http://www.atalasoft.com/kb/Article.aspx?id=10103
delete existing licence file
solve all errors
check properties of solution, DLL name, source name
rebuild the project