When I have an SQL Server Database project (.sqlproj) in Visual Studio solution, I notice that that particular project always gets built every time I build the solution even though there is no change in the project files.
This is inconsistent with normal C# project (.csproj) that only gets built when there is any file that changes.
I have tried cranking up the msbuild output verbosity, and it seems to always build that project without special reason.
Is there a reason why .sqlproj is always built? Is there a way to make it build only when file changes?
MSBuild has the opportunity to make Incremental Build. The main idea of that is the following:
MSBuild attempts to find a 1-to-1 mapping between the values of these attributes. If a 1-to-1 mapping exists, MSBuild compares the time stamp of every input item to the time stamp of its corresponding output item. Output files that have no 1-to-1 mapping are compared to all input files. An item is considered up-to-date if its output file is the same age or newer than its input file or files.
I don't know which targets are inside the *.sqlproj file, so you need to determine does it ever uses that technology, and if it do use - you need to examine which inputs and outputs involved, and try to clarify it by yourself, what is going on with them under the hood.
Related
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.
I'm using git to version control SSIS packages and I know that SSIS generates some crazy XML that is going to badly confuse any merge algorithms.
I'd like to know if having the following line in my .gitattributes file is the correct thing to do:
*.dtsx -diff
I believe this will stop git from attempting to merge the file, which is what I would like.
Am I correct in thinking that this also stops git from generating deltas and therefore stores every change as a whole file? (and therefore, takes up more storage)
My repository also holds the source for the database schema and any other source files, so I'm thinking that switching the repo to fast forward only is not appropriate.
if you don't want files to be merged in git, you need to use the -merge attribute. That way you can still be able to 'diff'.
We also treat packages as binaries, that does imply you will need to do changes multiple times if you need to do a patch from a branch and also need it in your main tree.
I'm writing a tool to automate documentation and deployment of code for our website and I came across an anomaly while testing and it throws into doubt my understanding of changesets.
What I'm seeing is a changeset referencing files that aren't actually part of the solution (although at one point they were).
As best as I can determine this is the series of events (all but the last step happened before I joined the company and so this is all deduced from source control history) :
A folder is added to a project containing around a dozen txt files which serve as templates for e-mails and these are checked in to TFS
2 weeks later four of the txt files are removed from the project but not physically deleted
2 years later a developer had a task to update e-mail templates and changed all the txt files in the folder including the four that aren't "in" the project
Developer checks in his changes resulting in Changeset X
When I look at Changeset X and its list of changes it includes an "edit" to each of the txt files including the four removed files. I've checked the CSPROJ file and there is definitely no reference to the removed files in there at the point the changeset was made.
When my code iterates through all the changes in the changeset it tries to marry up the changed file to the project it belongs to in order to identify what file(s) need to be deployed as a result of the change - ie if its .html or .jpg then it just gets copied but if its source code then I need to deploy the associated binary that gets compiled from the file). So when it finds these files and tries to find a project that they belong to it fails.
Should the changeset reference these removed files or is it a bug in TFS? Or could it be something that happened when the code was migrated from TFS 2008 to TFS 2012 at some time in the 2 years before the two changesets? If its not a bug then in what circumstances would you expect TFS to track changes to files not in the project?
I've tried to replicate it by setting up a totally new project and adding it to source control and then adding, removing and editing an associated text file but I can't get it to behave in the same way.
TFS is right. Visual Studio Solutions are a nice interface for visually managing a subset of files in Version Control. It is common to have more than one solution and change files in multiple places, but still is a single logical change that I want to record as a single changeset.
I am using VS2008 to publish my application files using ClickOnce. I read somewhere that ClickOnce intelligently does only partial updates; meaning it only downloads files from the network share if the file has changed in subsequent updates. However, this wasn't working for me. So I did some research and stumbled upon this MSDN article - http://msdn.microsoft.com/en-us/library/ms404267.aspx. It says that if we build using VS, it doesn't perform the partial updates. Can anyone tell me why this is the case? If so, is there a way to atleast let the referenced dlls to be downloaded only for the first time. I am using Microsoft Practices Enterprise Library and some 3rd party controls (with huge Theme files).
Thanks,
Uniball
Partial updates work fine in ClickOnce even when building in VS. However, if you have a solution made up of a few projects (eg a couple of class library projects and an executable) then any time you rebuild all the projects the timestamp on the assembly files will change, even if the code hasn't. Since ClickOnce really only looks at the timestamps to decide whether a file needs updating, it'll pull down the (unchanged) assemblies as new files when the user updates.
The workaround is to pull any dependent projects out of your executable's solution file and build them separately. That means that any assemblies whose code doesn't change very often will only get pulled down to the client once. If you need to change the assembly, you simply open its solution and make the change, then reopen your executable's solution and rebuild that. The next ClickOnce update will pull down both the exe and the changed assembly.
Hope that's clear enough!
I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed, even when I've made no changes to the project!
I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and is creating clutter in source control.
Is it possible to stop these changes from occurring, or get rid of the .dbmdl file whatsoever?
If you delete the .dbml file, it is rebuilt without errors or warnings, so I think it's just a cache file for references, intellisense, etc. I'm going to exclude it from source control.
I believe Visual Studio serializes the dbmdl file every time the project is opened. The only possible work around would be to keep the project open.
See related question here. The .dbmdl file is unique per user (and some kind of cache, as said above) and so the right solution is indeed to exclude it from source control.