What you want for 2.0? Please advise freely.

Topics: feature-request
Coordinator
May 21, 2010 at 12:54 PM

As titled. Please feel free to share your advice.

Jul 9, 2010 at 11:22 PM

Thanks for developing the tool. MSbuildShell hasn't been updated for so long and fortunately your tool works for .NET 4.0.

Is it possible to build the solution based on the Configuration Manager in Visual Studio? I have a couple of project that is not meant to compile, but MSBuildShell would try to compiling these project as well.

Thanks

Coordinator
Jul 18, 2010 at 8:35 AM

Hi,

Thanks for your comment.

Configuration Manager in Visual Studio has too many things so it is not easy to be emulated in a short period of time.

I did not yet have a clear roadmap for this project's 2.0 release. But any contribution is welcome.

It seems that you also experience an issue. Can you provide step by step description on how to reproduce it?

Regards,

Lex

Aug 4, 2010 at 9:39 AM

I would appreciate a feature that keeps the prompt and the error window open after the build is complete.

How  about converting this wonderful tool as Addin for Visual studio? VS doesnot show the build output in the color coded format, that Msbuild shows. Right now I am calling the mpad from VS using the custom buttons.


Coordinator
Aug 4, 2010 at 1:01 PM
Well, then you must understand the prompt and the error window only disappear if there is no error in the build process. Is this explanation OK for you? Visual Studio itself hooks to MSBuild API directly, so it does not use MSBuild.exe in any way. That prevents it from displaying the colors for users. mPad is mainly built for users who don't want to open VS to build a project, so currently there is no plan to build a VS addin in any way. We will evaluate such requests in the future and provide further feedbacks then. Thanks for your post. Lex
Aug 9, 2010 at 1:28 PM
Well I would appreciate a configuration where the output will remain even after a successful compilation. That is because, recently , I came across a problem where a command in the prebuild event script failed but the build succeeded. The same build was successful in MSBuild aswell. But the failing step was shown in red which helped me identify it. That is the reason why I want to call MSbuild once in a while from VS and manually verify no such failures (Red lines ) are there. Ya, I agree. As long as I can call the Mpad using custom buttons from the IDE , I can live without a addin.
Coordinator
Aug 29, 2010 at 1:16 PM

This requirement, "a configuration where the output will remain even after a successful compilation", is not easy to achieve, as that part is controlled by MSBuildShellExtension (http://msbuildshellex.codeplex.com/).

I may spare some time later this year to do more planning and hope we can find a proper way to achieve what you expect.

Regards,

Lex

Nov 4, 2010 at 7:04 PM

Is there a way to have Build/Clean/Rebuild directly in the context menu of explorer and bypass the dialog that pops up?  You could set some defaults as to which MSBuild version, as well as Debug or Release and never have to ask for the extra input that the dialog is gathering if you click one of the new buttons.

Coordinator
Nov 5, 2010 at 1:00 PM

Thanks for sharing your comments.

But that's something already implemented by MSBuild Shell Extension, so I suggest you take a look at it, http://msbuildshellex.codeplex.com/

We all know that we need different tools to meet different needs and there is nothing for all.

Regards,

Lex

Jan 10, 2011 at 8:39 PM

Thanks for developing this nice tool. I use it regularly.

I am currently using this tool on my Windows 7 machine. What I need to know is if it is possible to run the tool as Administrator when I right click a solution file in Windows Explorer. My solution contains C++ projects which register the assemblies after being built successfully and on Windows 7, that fails as the tool does not have necessary permissions to register the assemblies.

It would be great if you could add this to the next release.

Thanks again.

Coordinator
Jan 11, 2011 at 9:03 AM

Thanks for the suggestion. I think it is reasonable to provide such a feature for Windows Vista and Windows 7 users. The problem right now is how to properly implement it.

I will put it into our 2.0 feature list and start investigation.

Regards,

Lex

Jan 13, 2011 at 10:31 PM

Also, it will be nice to have keyboard support on the UI, like tabbing and hot keys, etc.

Coordinator
Jan 14, 2011 at 1:04 AM

Yes, that's a nice advice. I will carefully plan the keyboard shortcut, tabbing and hot keys.

Thanks,

Lex

Jan 14, 2011 at 9:12 AM

Hi Lex,

A couple of things:

  1. support for viewing the output of the build. Looks like I'm not the only one to feel the need for this... And it could be done quite easily, I think, by changing a couple of properties of StartInfo and redirecting the output to a read-only textbox
  2. support for MSBuild properties. Your suggestion works, of course, but explicit support instead of a workaround would be nice... Properties are just key/value pairs, after all - it should not require major GUI changes, I think?
  3. finally, were you aware that you could use the classes in Microsoft.Build.Engine to parse an MSBuild script? This will automatically load all imported scripts and saves you the effort of listing targets and find out the ToolsVersion...

Many thanks,

Fabio

Coordinator
Jan 15, 2011 at 10:02 AM

Hi Fabio,

Here are my comments,

1. Redirecting to a text box is not hard, but in that way you lose the colours. I don't know whether there is a way to draw the colours in the text box.

2. Explicit support requires some GUI changes I think. If you have a proposal on a new GUI design, you can send to me via email and we can extend the discussion (me@lextm.com).

3. Using MSBuild API requires mPad to link to MSBuild assemblies. This dependency can lead to various problems which I was trying to avoid. For example, if I build mPad against .NET 2.0 MSBuild assemblies, will it work on a machine with only .NET 4 MSBuild assemblies available? That's why I rather give up its advantages. I don't think it is time to change the current approach but I am open to discussion.

Regards,

Lex

Jan 17, 2011 at 7:58 AM

Hi Lex,

  1. Yes, I agree - embedding an actual console with colors and all would be much better, but it's certainly a lot more work, if at all possible. However, as a way to just view the output of the build a simple textbox would be better than nothing for me (and it can always be hidden/shown with a checkbox or something)
  2. I'll send you a couple of screenshots for this, essentially I was thinking of a pair of dropdown lists one with keys and the other with values
  3. You could always package the .NET 2.0 MSBuild assemblies with mPad - this way, if it's not in the GAC, it will be loaded from the mPad folder

Fabio

Jan 17, 2011 at 1:59 PM

RE Properties - Probably a pair of dropdown lists is not the best choice after all...

I'm struggling to find an elegant solution, and I'd really hate to clutter the UI because it's really nice and sleek the way it is.

The best solution, I think, is to create "strongly-typed" MSBuild targets, like so - suppose you have a target which uses a property:

  <PropertyGroup>
    <Config>Debug</Config>
  </PropertyGroup>
  
  <Target Name="Test">
    <Message Text="$(Config)" />
  </Target>

Then I would include an additional target, like so:

  <Target Name="TestWithProp">
    <MSBuild Projects="$(MSBuildProjectFile)" Targets="Test" Properties="Config=Release" />
  </Target>

This, of course, only works if we know the possible values for each property at design time, i.e. if the property is an enum and not a free-text string...

And if a target uses more than one property, the total number of combinations of all values could be very high, meaning a lot of "strongly-typed" targets would have to be created...

Fabio

 

 

Feb 23, 2011 at 5:00 PM

Hi Lex,

I noticed one behavior with mPad. When the build completes with errors, it shows all errors on the Error List, but, on the main window, the progress bar still continues to show that the build is still in progress.

This leads to confusion. I think, when the build completes, the progressbar should stop moving. 


Ashish

Mar 27, 2014 at 12:38 PM
Hi,
Thank you for an awesome tool.
I have a suggestion, if the build configuration has spaces on it you have to quote unquote it in the combo box, that is not fun

Example:

Configuration:
Debug - No Raz

you'll have to type

"Debug - No Raz" or the msbuild will crash trying to understand the - No Raz as a switch

Can you add the quotes automatically?

Thanks
Coordinator
Mar 28, 2014 at 3:24 AM
Edited Mar 29, 2014 at 6:43 AM
Hi,

Thanks for reporting the quote issue as I am not aware of it in the past.

Fixed in https://msbuildlaunchpad.codeplex.com/releases/view/47157

Lex
Mar 29, 2014 at 11:26 AM
Thanks! Latest build seems to work without quotes! awesome!
Jul 15, 2014 at 5:34 PM
I really like the dialog, since it lets you easily retry if a build fails (say a dependency is not updated), but I would also love it if there was an option to build automatically as soon as the dialog open.

Another thing that would be awesome (and could help with the above) is if the app could build a cache and save settings per project/sln. That way it could be a check mark that says automatically start build for this project, and since all the configs for the project are saved, it should be all right.

Thanks for the great work!