Response to the feature poll

re: Response to the feature poll

Eric Hauser — Fri, 30 Nov 2007 20:48:34 GMT

Dan,

Has there been any discussion of supporting remote dependencies via HTTP a la Maven? Supporting the ability to pull assemblies from a remote location such as corporate repository or open source repository would be a great feature.

re: Response to the feature poll

msbuild — Fri, 30 Nov 2007 21:22:43 GMT

@Eric,

No, I've never heard that request. This would be pulling assemblies that you require but you yourself haven't built, because you haven't changed the code or haven't enlisted in the code?

In the MSBuild world, this would be accomplished by writing a task. Our existing ResolveAssemblyReference task doesn't currently have the ability to look in remote locations except via UNC.

Dan

re: Response to the feature poll

Simon — Fri, 30 Nov 2007 23:13:54 GMT

Regarding visualization, there's http://www.codeplex.com/dependencyvisualizer

that you may find useful.

</shameless plug>

re: Response to the feature poll

Eric Hauser — Fri, 30 Nov 2007 23:18:04 GMT

Dan,

Yes, exactly. For example, I have an open source project that I want to use in my application. Today, I download the assembly and place it in a folder, then add a hardcoded reference in Visual Studio to the location. When I use Java and Maven, I add a depenency to a project and a version in my configuration and it handles the rest (going to the repository, downloading the library, downloading any transitive dependencies).

This approach also allows you to establish a corporate repository for shared libraries.

I looked at the ResolveAssemblyReference task and the concept is similar. The downside with UNC is that repositories cannot be accessed outside the firewall. However, Visual Studio will not know about these assembly references until I build the project though, correct? That would be an issue for anyone who uses ReSharper, CodeRush, or anything else that does incremental compilation of your project from inside VS.

re: Response to the feature poll

msbuild — Fri, 30 Nov 2007 23:47:21 GMT

@Eric,

You should be able to write a task that resolves selected items in the @(Reference) list, caching them locally and adding HintPath metadata to the items as appropriate. If this runs before ResolveAssemblyReference then it will be able to find the reference at the hintpath.

As for design time support, if you make the ResolveAssemblyReference target depend on the target you created containing your task, then I believe that Visual Studio should be able to resolve references at design time, since it calls the ResolveAssemblyReference target directly at that time. I haven't had a chance to try this though.

Dan

Visual Debugger for MSBuild Projects

Partho's Weblog — Sat, 01 Dec 2007 17:16:27 GMT

Folks, Hi! A recent feature poll on the MSBuild blog seems to indicate that a debugger for MSBuild projects

re: Response to the feature poll

Partho — Sat, 01 Dec 2007 18:16:42 GMT

Here is a debugger for MSBuild Projects http://blogs.msdn.com/parthopdas/archive/2007/12/01/visual-debugger-for-msbuild-projects.aspx

MSBuild Debuggers!

John Robbins' Blog — Mon, 03 Dec 2007 07:38:28 GMT

It looks like I'm not the only one who wanted a debugger for MSBuild projects. When the MSBuild team

Debuggability tops MSBuild feature poll

Noticias externas — Tue, 04 Dec 2007 06:02:10 GMT

Dan Mosely recently posted a feature poll on the MSBuild blog . Here are the results . Debuggability

Most Wanted: Debugging For MSBuild

Maor David — Wed, 05 Dec 2007 00:25:19 GMT

I posted few weeks ago about the feature poll of MSBuild team on the MSBuild blog . Here are the results

VSTS Links - 12/05/2007

Team System News — Wed, 05 Dec 2007 15:00:29 GMT

The Visual Studio Team System User Education Blog on New End to End Articles for Visual Studio Team System...

re: Response to the feature poll

Eric Bickle — Fri, 07 Dec 2007 23:08:54 GMT

Hi Dan,

I apologize for missing the original poll, but I really like the overall direction MSBuild is going and how the team is involving the development community in the process!

Unfortunately, something very important was left off the list - the ability to centrally control versioning.

A core component of *every* build is the build version - it's basically impossible to release anything but a tiny application without a standardized version numbering system.

Even before MSBuild was planned, Visual Studio (and before it, Visual C++) has never made comprehensive version number support a priority - developers have been suffering for decades. Every time it's brought up, we seem to be told "no time to do it now, we'll postpone it until a future release".

It's been 15(?) years since MSVC's release - I'd really love to see someone take ownership of the issue and really drive this one home for the next release. Now that we have MSBuild, Microsoft now has a team that has a core requirement for centralized versioning.

I'm sure other people have different ideas, but the problems I've been running into are:

* MSBuild has no native tasks for generating and incrementing a build number. I realize each company has a different concept of what a build number is, but at least a basic task that shops needing a more customized solution could override.

* MSBuild has no centralized concept of a version number (ie/ the version # built built). Although I could hack this into four properties: (major, minor, build, release) I strongly believe this should be built-in to MSBuild. How many products to you know of that don't have versions? This could potentially be blank/disabled/etc for shops that don't want centralized versioning.

* The .NET MSBuild project files (vbproj, csproj, etc) don't have version number as a "project setting". Right now, versions are placed on assemblies via attributes (typically in the "AssemblyInfo" source files). The lack of a project setting/msbuild property makes it impossible to override via MSBuild. Take, for example, .NET 2.0. .NET 2.0 moved the DelaySign/KeyFile/etc attributes out of AssemblyInfo and into the project file for similar reasons - so that the build team wouldn't need to release the private keys to the development team.

We *DESPERATELY* need the same thing done for version numbers - leave the old AssemblyVersion and AssemblyFileVersion attributes deprecated and provide a (MSBuild) project-level setting. People without centralized builds can still specify a version in the project settings, but it can be overriden via MSBuild for centralized versioning.

Camp out in front of the C# and VB teams doors! Don't let them out until they commit to adding this in the next release! I can beg! I can send bribes!!! ;-)

You alluded to the fact that the VC team /may/ be adding native MSBuild project files in the next release (tenatively). If this happens, they really need to do the same thing. I realize it's a little trickier for them given the nature of the VC compiler, but I don't see why it's not possible. VC has never even remotely had the concept of a version (aside from hard-coded RC files that can't be touched by MSBuild).

At my company, I'm the "owner" of both the build process and the installer. Versioning has always been the most painful part of the process to deal with - it's been forgotten for far too long. Definately would be my #1 request (solutions as #2).

Taking a look at VS2008 and how the Windows SDK was finally decoupled from Visual Studio itself really warmed my heart last night! Now my build server can finally have a single, definitive set of tools and libraries! WOOHOO! ;-)

:-)

re: Response to the feature poll

msbuild — Sat, 08 Dec 2007 00:48:46 GMT

@Eric Bickle

Thanks for the interesting comments. You saw #12 above, which I suppose would be a Microsoft task that would automatically edit your assemblyinfo.xx to update your version number. For managed code, the assembly version must (as far as I know) be fed to the compiler in source code, generally implying editing assemblyinfo.xx in this way. I do not know exactly what TeamBuild expects to offer here for Rosario, but I assume it would be possible to pass in the version # to this task as an MSBuild property. That could originate in the project file, the environment, or from the command line. I'll forward this to Buck in TeamBuild to see what he says.

As for native code, I'll forward this on to the VC team responsible for their MSBuild support.

Dan

re: Response to the feature poll

msbuild — Sat, 08 Dec 2007 00:54:05 GMT

@Eric Bickle (continued)

Let me ask specifically since I'm not sure: you mention "MSBuild has no centralized concept of a version number". What would you want exactly? Would a task editing the assemblyinfo configurable from a project/command line be sufficient?

re: Response to the feature poll

Eric Bickle — Mon, 10 Dec 2007 21:44:03 GMT

> "MSBuild has no centralized concept of

> a version number". What would you want

> exactly? Would a task editing the

> assemblyinfo configurable from a

> project/command line be sufficient?

Originally I was thinking of having version number be a reserved property name within MSBuild - but adding that would likely be a breaking change.

Perhaps a small task built in to MSBuild would be sufficient to perform versioning into properties.

* Four "ushort" outputs (Major, Minor, Release, Build)

* String outpit returning concatenated version (Major.Minor.Release.Build or Major.Minor.Build.Release, depending on which api you base it on ;-)

* String input pointing to the path of a file the task will "own". The file will contain the last version number. The task reads the file, parses it, increments the version if necessary, saves the changes, and returns the new version into the output parameters.

* Four boolean inputs, determining which components should be auto-incremented. Defaults to true.

For example, if I called:

<GenerateVersion

File="C:\Build\BuildVersion.dat"

IncrementBuildNumber="True">

<Output

TaskParameter="Version"

PropertyName="BuildVersion" />

</GenerateVersion>

It would read and parse BuildVersion.dat (if it doesn't exist, the task fails). If the version it read was 1.1.20.2354, it would return "1.1.20.2355" since "IncrementBuildNumber" is true.

In response to your comment about #12, which is assemblyinfo.xx support, I believe it's a good idea for inclusion within MSBuild. Technically speaking, there is no requirement that specifies where the AssemblyVersion and AssemblyFileVersion attributes need to be placed. By convention, Visual Studio's IDE places them in the AssemblyInfo.?? files, but it's not a requirement. In .NET 2.0, Visual Studio modified the attributes that were placed into the AssemblyInfo files - you wouldn't want to create an MSBuild task that gets shipped as part of the framework only for it to become obsolete due to an IDE change. It also might not be a good idea to put Visual Studio specific tasks into a component that ships as part of the Framework itself.

My argument was that AssemblyVersion and AssemblyFileVersion attributes should be deprecated within the framework (or at least deprecated by convention, if not the DeprecatedAttribute()).

In the VS2005/.net 2.0 release, certain attributes that were originally placed in the AssemblyInfo by Visual Studio were moved out into the project file. If you fire up a C# project in VS2005 and go to the project properties, on the Signing tab you will see settings for "Sign the assembly" and "Choose a strong name key file". In VS2003/20002, those project settings didn't exist - they were hardcoded as attributes, typically within AssemblyInfo.??

My argument is that Versioning should be dealt with the same way. Versions are generally not regarded as static code, and therefore they don't belong in a code file.

I would envision the change being something along these lines:

* Add a switch to the .net compilers that allows a version number to be specified. For example, csc.exe /assemblyversion:1.1.34.1234. If the switch is specified, it overrides the "AssemblyVersion" and "AssemblyFileVersion" attributes.

* Modify the .net compiler tasks in MSBuild so that they include a "AssemblyVersion" property. The task would pass the value into csc.exe, similar to the other properties.

* Optionally change the next version of Visual Studio so that developers can specify the version number in the project settings page, similar to older versions of VB. This would not be a breaking change (or required), since the AssemblyVersion and AssemblyFileVersion attributes still work normally unless they are overriden by the optional new behavior.

In C#'s case, csc.exe is responsible for generating the .NET assembly from C# code. Csc is responsible for reading the attributes and placing them in the "unmanaged" fileinfo block of the generated assembly. Adding a command switch would give MSBuild developers the flexibility of centrally controlling version numbering during the build.

No VS-specific AssemblyInfo file rewriting required ;-)

The problem with the idea is that it requires buy-in from the teams responsible for the .net compilers - but it should be fairly easy to make a strong case why the change would be a good idea.

Thanks again for the quick response and considering the suggestions!

re: Response to the feature poll

msbuild — Mon, 17 Dec 2007 22:50:09 GMT

@Eric

This is very useful -- I'm passing it along to the team build people who are planning to add assembly version support in Rosario.

Do you use VS team build? Or would you envision it being available outside team build?

Dan

MSBuild Sidekick v2 Q&A session

Team Foundation Sidekicks — Wed, 19 Dec 2007 10:44:26 GMT

With the release of MSBuild Sidekick v2 , several questions have been asked repeatedly. But what is the

Distributed Builds

Andre Weissflog (floh@radonlabs.de) — Thu, 20 Dec 2007 18:41:13 GMT

Distributed builds would be a big deal for us as a game company (yes I voted form them). We have been doing our project builds with MSBuild for quite a while now. Our build process basically looks like this:

(1) pull latest version from version control

(2) recompile executables

(3) batch-export graphics objects from Maya format to our engine format using our own batch-exporter

(4) batch-convert textures from .psd to .dds

(5) export levels and other game data into a SQLite database

(6) pack assets into archives

(7) build an installer

(8) ftp-upload the resulting files

A typical game consists of about 20,000 to 30,000 source asset files and compiles into about 2..7 GB of data. A full build takes up to 11 hours.

An MSBuild tool with built-in support for distributed builds could help us to split the critical steps (3) and (4) across several machines without too much hassle.

MSBuild is great by the way ;)

re: Response to the feature poll

Eric Bickle — Tue, 25 Dec 2007 01:09:13 GMT

Thanks Dan (and the rest of the team) - I'm glad you found the feedback useful!

Presently we're a small shop of about 6 developers writing larger scale applications (distributed client/server, at least 4 tiers) targeted for 10,000+ users.

In that sense we're a little unusual - but Team Build is out of our league right now. (Seems to be targed for organizations > 100 devs, etc). The '5 user' edition of team studio is too restrictive for our environment as well.

I would envision this working outside of team build - right now we have a build server running custom msbuild scripts which handle source control, file copies, etc and hand off the actual build of the application's individual tiers to (unmodified) Visual Studio solutions and project files.

I find the compiler-level solution so appealing because any build framework could potentially hook into it, whether it's MSBuild, Team Studio Build Server, NAnt, etc. Support in Team Studio would be nice, but it still doesn't address the limitation in the .NET compilers in regards to assembly versioning.

Right now I visualize the minimum required changes for this to work would be the modifications to the compilers for the version override and a slight adjustment to the MSBuild target files - anything else is a major bonus (ie/ Visual Studio or Team Build support).

Hope that answers your question!

Smarter Logging with MSBuild

John Robbins' Blog — Thu, 17 Jan 2008 19:25:37 GMT

MSBuild has made my life so much easier that it makes me shudder thinking back to the days of NMAKE.

Visual Debugger for MsBuild

ascend slowly, breathing normally — Wed, 26 Mar 2008 06:05:15 GMT

Are you looking for a visual debugger for MsBuild? It seems like lots of folks are. Looking at the results

printf(“Hello MSBuild!\n”);

Visual C++ Team Blog — Fri, 21 Nov 2008 03:27:29 GMT

Hello everyone. I’m Marian Luparu and I am a Program Manager in the Visual C++ IDE team. Last week I

Path length limit 248/260 characters

NTR — Mon, 08 Dec 2008 17:48:30 GMT

What about fixing something that everybody at some point encounters. The use of absolute paths and the related maximum characters error. This is a constant annoyance for us, since we try to honor .NET naming guidelines and try to give products real names instead of acronyms or similar. And windows does support paths longer than 256 so why this limit?

The error: Typically with $(FullName) something:

The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

re: Response to the feature poll

msbuild — Tue, 09 Dec 2008 02:25:17 GMT

@NTR

I wish we could. We are dependent on the support from .NET framework/CLR API's - they are doing some work on it (http://blogs.gotdotnet.com/bclteam/archive/2008/07/07/long-paths-in-net-part-3-of-3-redux-kim-hamilton.aspx) but it is too limited for MSBuild because many Win32 API's don't support long paths.

If this sounds like passing the buck, because we're all Microsoft, I wholeheartedly agree. But another way of looking at it is that it would need changes in an enormous number of places right down the stack. Think of all the statically sized buffers in C++ apps for example. So it would take overwhelming agreement from customers that it is worth doing instead of other work.

Hope that makes sense,

Dan

re: Response to the feature poll

Kate — Wed, 17 Dec 2008 18:00:45 GMT

Exciting perspectives!

And there’s an interesting fact - you can get the Editing UI feature as a part of Automated Build Studio installation package (by AutomatedQA). Also there are some other features from the list above. The macros can be used for extending MSBuild projects. Check it: http://www.automatedqa.com/techpapers/abs_vs_msbuild.asp

re: Response to the feature poll

Matt Houser — Fri, 19 Dec 2008 04:56:20 GMT

For those of you using vc builds (not msbuild), you can use VersionUtil to update the build number as a post build event in your .vcproj files.

http://www.insidercoding.com/page/VersionUtil.aspx

Feature requests are welcome.

re: Response to the feature poll

Ike Butler — Wed, 18 Feb 2009 21:06:55 GMT

Hello. I have a bit of a problem and was wondering if anyone could offer a possible resolution and/or lead towards finding a solution to my problem.

I'm working with project templates via VS2008 Professional Team.

I'm able to easily add the neccessary references to my templated project, but where I run into problems is trying to rename the default class.cs file associated with making a new project.

Could anyone tell me how to take my formatted (templated Class1.cs) file and rename it to something else?

ie. Class.cs -> MyClassName.cs within the template.

I used this template file:

<Name>DMIBusiness Objects</Name>

<Description>Extended DMI Business Object Assembly</Description>

<ProjectType>CSharp</ProjectType>

</ProjectSubType>

<DefaultName>DMIBusiness Objects</DefaultName>

<LocationField>Enabled</LocationField>

<Icon>__TemplateIcon.ico</Icon>

</TemplateData>

<Project TargetFileName="DMIBusiness Objects.csproj"

File="DMIBusiness Objects.csproj"

ReplaceParameters="true">

<ProjectItem ReplaceParameters="true"

TargetFileName="AssemblyInfo.cs">AssemblyInfo.cs</ProjectItem>

</Folder>

</Project>

</TemplateContent>

</VSTemplate>

I even tried changing it within the Project.TargetFileName to:

TargetFileName="$safeprojectname$.cs"???

Help

MSBuild Sidekick v 2.3 is released

Team Foundation Sidekicks — Wed, 25 Mar 2009 07:01:04 GMT

We are happy to announce the release of version 2.3 of MSBuild Sidekick! Many of you would remember "

Debug your build with MSBuild Sidekick v2.3

Buck Hodges — Mon, 30 Mar 2009 19:59:56 GMT

The folks at Attrice have released a new version of their MSBuild Sidekick , and it now includes a visual