In previous blog post, we discussed about the concept of properties in MSBuild schema. We also saw few project files samples and about reserved properties. In this post, we are going to expand that knowledge by discussing how to use properties further.
Access Environment Variables
In some build configurations, when you build projects, it is often necessary to set build options using information that is not in the project file. This information is typically stored in environment variables. All environment variables are available to the MSBuild as properties. So we can simply access them in the same way we access properties i.e. by encapsulating their name in $(environmental_variable_name). Continue reading “Understanding Microsoft Build System – Making use of Properties”→
In one of the previous post, we discussed about the significance of MSBuild and how to download it. We have also seen the very basics of schema that is needed by MSBuild. In this blog post, we are going to expand on the same by discussing Properties.
Concept of Properties
When you build projects, you frequently compile the source code with different build options. For example, for development environment release, you generally create a build with debug configuration with symbols so that the developers can use it to help finding bugs. For production release, you generally create a build with no symbol information. You would also like to also enable optimizations if its possible. Continue reading “Understanding Microsoft Build System – Properties”→
Octopus server has become wildly popular these days for continuous deployments because of its features, extensibility and integration with continuous integration tools like Jenkins or Bamboo. It can be used to deploy applications and perform complex steps to servers located either in cloud or on-premise. It also supports latest inclusion of latest DevOps technology like containers.
MSBuild is perhaps one of the most used but uncredited piece of technology. The Microsoft Build Engine or more known as MSBuild, is a platform for building applications. Chances are that if you have ever used Visual Studio or compiled a .NET based project, you have used it knowingly or un-knowingly. Visual Studio uses MSBuild, but it doesn’t depend on Visual Studio. By invoking msbuild.exe on your project or solution file, you can orchestrate and build products in environments where Visual Studio is not installed. For MSBuild to work properly, you need to use an XML schema that defines how the build platform processes and builds software.
In previous blog post, we learned how to analyze a commit. We now will proceed to understand the various stages of commit and types of them as well.
As we all know, Git has 3 places for the code:
– Working tree: The place where we can add, modify source code.
– Staging area: The contents of modified files in the working tree are temporarily stored to a staging area called the “index” with git add. A file can be reverted back, only in the index but not in the working tree, to that of the last commit with git reset HEAD — , which effectively reverts git add and prevents the changes to this file from participating in the next commit.
– Local repository: git commit (without any pathname parameter) is used to record what has been staged so far in its most basic form. Continue reading “Integration of Git and Visual Studio – Commit variations”→
In previous blog post, we learned how to create a git repository and commit first using Visual Studio and then achieve the equivalent of same using the native git commands. In this blog post, we’ll learn how to see the specifics of commit or how git stores this information.
Let’s analyze commit made by using Visual Studio, using the project ConsoleApp02. If we navigate to the project directory and do a git log, we’ll see below output:
I recently came across few blogs discussions where the question was whether you should be using some kind of UI tool for git or live with the command line git and which one is better. I won’t go much into the debate of which one is better, but I can say that you should know what you are doing. Each UI based implementation of git takes away all those commands and command line interface, it provides a nice usable interface to its users. However command line git can be very very powerful if you know what you are doing and you do need to have that kind of control sometime. So we need to understand what is happening behind-the-scenes.