Search Results

Search found 705 results on 29 pages for 'msbuild propertygroup'.

Page 8/29 | < Previous Page | 4 5 6 7 8 9 10 11 12 13 14 15  | Next Page >

  • When implementing a microsoft.build.utilities.task how to i get access to the various environmental

    - by Simon
    When implementing a microsoft.build.utilities.task how to i get access to the various environmental variables of the build? For example "TargetPath" I know i can pass it in as part of the task XML <MyTask TargetPath="$(TargetPath)" /> But i don't want to force the consumer of the task to have to do that if I can access the variable in code. http://msdn.microsoft.com/en-us/library/microsoft.build.utilities.task.aspx

    Read the article

  • How to copy a folder recursively with out overwriting the previous one

    what i need is i have linked my project with the cruise control, so when ever a build happens i want to copy the bin folder to a seperate destination folder with version number. That is when the project build happens for the second time i dont want to replace the bin folder of the first build i want to save this with another version number. How can i do that. Right now i got the thing how to copy the folder but it was overwriting the previous one. i dont want that to happen please help me how to implement the concept of versioning.

    Read the article

  • MSBuild: convert relative path in imported project to absolute path.

    - by Ergwun
    Short version: I have an MSBuild project that imports another project. There is a property holding a relative path in the imported project that is relative to the location of the imported project. How do I convert this relative path to be absolute? I've tried the ConvertToAbsolutePath task, but this makes it relative to the importing project's location). Long version: I'm trying out Robert Koritnik's MSBuild task for integrating nunit output into Visual Studio (see this other SO question for a link). Since I like to have all my tools under version control, I want the target file with the custom task in it to point to the nunit console application using a relative path. My problem is that this relative path ends up being made relative to the importing project. E.g. (in ... MyRepository\Third Party\NUnit\MSBuild.NUnit.Task.Source\bin\Release\MSBuild.NUnit.Task.Targets): ... <PropertyGroup Condition="'$(NUnitConsoleToolPath)' == ''"> <NUnitConsoleToolPath>..\..\..\NUnit 2.5.5\bin\net-2.0</> </PropertyGroup> ... <Target Name="IntegratedTest"> <NUnitIntegrated TreatFailedTestsAsErrors="$(NUnitTreatFailedTestsAsErrors)" AssemblyName="$(AssemblyName)" OutputPath="$(OutputPath)" ConsoleToolPath="$(NUnitConsoleToolPath)" ConsoleTool="$(NUnitConsoleTool)" /> </Target> ... The above target fails with the error that the file cannot be found (that is the nunit-console.exe file). Inside the NUnitIntegrated MSBuild task, when the the execute() method is called, the current directory is the directory of the importing project, so relative paths will point to the wrong location. I tried to convert the relative path to absolute by adding these tasks to the IntegratedTest target: <ConvertToAbsolutePath Paths="$(NUnitConsoleToolPath)"> <Output TaskParameter="AbsolutePaths" PropertyName="AbsoluteNUnitConsoleToolPath"/> </ConvertToAbsolutePath> but this just converted it to be relative to the directory of the project file that imports this target file. I know I can use the property $(MSBuildProjectDirectory) to get the directory of the importing project, but can't find any equivalent for directory of the imported target file. Can anyone tell me how a path in an imported file that is supposed to be relative to the directory that the imported file is in can be made absolute? Thanks!

    Read the article

  • Team Foundation Server – How to pass ReferencePath argument to MSBuild

    - by Gopinath
    When we manually build a .NET project using Visual Studio, the reference paths set in Project Properties are picked up by Visual Studio for referring to dependent DLLs. But the project is built using TFS, the reference path’s specified in project properties are not considered. This is because Reference Paths are user specific settings and they are not stored in .proj files(they are stored in user settings files). The TFS build may break if it does not find the required DLLs in GAC. We can solve the problem by passing ReferencePath parameter to MSBuild in TFS build configurations. Go to Team Explorer Select Build Defintion >> Edit Build Definition Switch to Process tab Navigate to Advanced Section and locate MSBuild Arguments Add the following: /p:ReferencePath=”{File path}”

    Read the article

  • How can I get TFS2010 to run MSDEPLOY for me through MSBUILD?

    - by Simon_Weaver
    There is an excellent PDC talk available here which describes the new MSDEPLOY features in Visual Studio 2010 - as well as how to deploy an application within TFS. You can use MSBUILD within TFS2010 to call through to MSDEPLOY to deploy your package to IIS. This is done by means of parameters to MSBUILD. The talk explains some of the command line parameters such as : /p:DeployOnBuild /p:DeployTarget=MsDeployPublish /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=InProc /p:MSDeployServiceURL=localhost /p:DeployIISAppPath="Default Web Site" But where is the documentation for this - I can't find any? I've been spending all day trying to get this to work and can't quite get it right and keep ending up with various errors. If I run the package's cmd file it deploys perfectly. But I want to get the whole deployment running through msbuild using these arguments and not a separate call to msdeploy or running the package .cmd file. How can I do this? PS. Yes I do have the Web Deployment Agent Service running. I also have the management service running under IIS. I've tried using both. Args I'm using : /p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:Configuration=Release /p:CreatePackageOnPublish=True /p:DeployIisAppPath=staging.example.com /p:MsDeployServiceUrl=https://staging.example.com:8172/msdeploy.axd /p:AllowUntrustedCertificate=True giving me : C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (2660): VsMsdeploy failed.(Remote agent (URL https://staging.example.com:8172/msdeploy.axd?site=staging.example.com) could not be contacted. Make sure the remote agent service is installed and started on the target computer.) Error detail: Remote agent (URL https://staging.example.com:8172/msdeploy.axd?site=staging.example.com) could not be contacted. Make sure the remote agent service is installed and started on the target computer. An unsupported response was received. The response header 'MSDeploy.Response' was '' but 'v1' was expected. The remote server returned an error: (401) Unauthorized.

    Read the article

  • What type of things can cause sgen msbuild task to fail intermittantly with Access Violation?

    - by Mark Allanson
    In our MSBuild file for our project we sgen an assembly containing classes used during xml serialization. The classes are generated via xsd.exe. We use the following SGen task configuration. <SGen ToolPath="$(SdkPath)" ShouldGenerateSerializer="true" UseProxyTypes="false" BuildAssemblyName="AssemblyName.dll" BuildAssemblyPath="Outputs" ContinueOnError="false" /> Intermittantly the following error is thrown when executing the msbuild script on our build server. Originally this error might have occurred once out of every 50 (CI) builds, recently the frequency has been increasing and it now occurs maybe 5-6 out of every 10 builds. The size of the assembly that is being Sgenned is about 410k (circa 35,000 lines of generated code), and when successfull the serialization assembly is about 1.7M in size. When it fails, the output is as follows: Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. E:\Path_ToBuild_Workspace\SolutionBuild.MSBuild(74,5): error MSB6006: "sgen.exe" exited with code -1073741819. We are using Hudson to manage our builds, so the msbuild and sgen processes are therefore spwaned by the Hudson.exe. There's not much out there on the interwebs regarding this type of error from SGen. Certainly nothing concrete.

    Read the article

  • How to Integrate ILMerge into C#/VB.NET (MSBuild) Projects to Merge Assemblies?

    - by AMissico
    I want to merge one .NET DLL assembly and one C# Class Library project referenced by a VB.NET Console Application project into one command-line console executable. I can do this with ILMerge from the command-line, but I want to integrate this merging of reference assemblies and projects into the Visual Studio project. From my reading, I understand that I can do this through a MSBuild Task or a Target and just add it to a C#/VB.NET Project file, but I can find no specific example since MSBuild is large topic. How do I integrate ILMerge into a Visual Studio (C#/VB.NET) project, which are just MSBuild projects, to merge all referenced assemblies (copy-local=true) into one assembly? How does this tie into a possible ILMerge.Targets file?

    Read the article

  • Logs overwritten in CruiseCControl.NET when there is multiple MSBuild Tasks.

    - by James Poulose
    I have two MSBuild tasks in my CC.NET config. In the end of the execution, i can see two blocks of warnings/errors in the log and published email. But the problem is that the contents of both the blocks are the same and that is from the second MSBuild task!! In another way, the second MSBuild task overwrites the first log, and then creates another one for itself effectively creating two exactly identical block!!! Do anybody have any thoughts on this? I am happy to provide more information if you require about the environment and configuration. Thanks, James Poulose

    Read the article

  • Where does MSBuild store it's options, and how can I change them?

    - by Neil
    We have a large project at work, under source control, including an MSBuild file to run the build. Recently, the build has stopped working on my machine (I get errors saying that 'zzz' is ambiguous in the namespace 'yyy'). The same MSBuild file is working fine on both the build server and my co-workers machines. I have tried cloning a new copy of the project from the shared repository, but even with a clean copy, the build is failing for me. I think it must be a problem with the MSBuild settings on my machine, but I haven't been able to find anything that tells me where they are. Any help would be appreciated, since I'm starting to think my machine has just gone crazy.

    Read the article

  • How to troubleshoot a 'System.Management.Automation.CmdletInvocationException'

    - by JamesD
    Does anyone know how best to determine the specific underlying cause of this exception? Consider a WCF service that is supposed to use Powershell 2.0 remoting to execute MSBuild on remote machines. In both cases the scripting environments are being called in-process (via C# for Powershell and via Powershell for MSBuild), rather than 'shelling-out' - this was a specific design decision to avoid command-line hell as well as to enable passing actual objects into the Powershell script. The Powershell script that calls MSBuild is shown below: function Run-MSBuild { [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Build.Engine") $engine = New-Object Microsoft.Build.BuildEngine.Engine $engine.BinPath = "C:\Windows\Microsoft.NET\Framework\v3.5" $project = New-Object Microsoft.Build.BuildEngine.Project($engine, "3.5") $project.Load("deploy.targets") $project.InitialTargets = "DoStuff" # # Set some initial Properties & Items # # Optionally setup some loggers (have also tried it without any loggers) $consoleLogger = New-Object Microsoft.Build.BuildEngine.ConsoleLogger $engine.RegisterLogger($consoleLogger) $fileLogger = New-Object Microsoft.Build.BuildEngine.FileLogger $fileLogger.Parameters = "verbosity=diagnostic" $engine.RegisterLogger($fileLogger) # Run the build - this is the line that throws a CmdletInvocationException $result = $project.Build() $engine.Shutdown() } When running the above script from a PS command prompt it all works fine. However, as soon as the script is executed from C# it fails with the above exception. The C# code being used to call Powershell is shown below (remoting functionality removed for simplicity's sake): // Build the DTO object that will be passed to Powershell dto = SetupDTO() RunspaceConfiguration runspaceConfig = RunspaceConfiguration.Create(); using (Runspace runspace = RunspaceFactory.CreateRunspace(runspaceConfig)) { runspace.Open(); IList errors; using (var scriptInvoker = new RunspaceInvoke(runspace)) { // The Powershell script lives in a file that gets compiled as an embedded resource TextReader tr = new StreamReader(Assembly.GetExecutingAssembly().GetManifestResourceStream("MyScriptResource")); string script = tr.ReadToEnd(); // Load the script into the Runspace scriptInvoker.Invoke(script); // Call the function defined in the script, passing the DTO as an input object var psResults = scriptInvoker.Invoke("$input | Run-MSBuild", dto, out errors); } } Assuming that the issue was related to MSBuild outputting something that the Powershell runspace can't cope with, I have also tried the following variations to the second .Invoke() call: var psResults = scriptInvoker.Invoke("$input | Run-MSBuild | Out-String", dto, out errors); var psResults = scriptInvoker.Invoke("$input | Run-MSBuild | Out-Null", dto, out errors); var psResults = scriptInvoker.Invoke("Run-MSBuild | Out-String"); var psResults = scriptInvoker.Invoke("Run-MSBuild | Out-String"); var psResults = scriptInvoker.Invoke("Run-MSBuild | Out-Null"); I've also looked at using a custom PSHost (based on this sample: http://blogs.msdn.com/daiken/archive/2007/06/22/hosting-windows-powershell-sample-code.aspx), but during debugging I was unable to see any 'interesting' calls to it being made. Do the great and the good of Stackoverflow have any insight that might save my sanity?

    Read the article

  • CI Deployment Of Azure Web Roles Using TeamCity

    - by srkirkland
    After recently migrating an important new website to use Windows Azure “Web Roles” I wanted an easier way to deploy new versions to the Azure Staging environment as well as a reliable process to rollback deployments to a certain “known good” source control commit checkpoint.  By configuring our JetBrains’ TeamCity CI server to utilize Windows Azure PowerShell cmdlets to create new automated deployments, I’ll show you how to take control of your Azure publish process. Step 0: Configuring your Azure Project in Visual Studio Before we can start looking at automating the deployment, we should make sure manual deployments from Visual Studio are working properly.  Detailed information for setting up deployments can be found at http://msdn.microsoft.com/en-us/library/windowsazure/ff683672.aspx#PublishAzure or by doing some quick Googling, but the basics are as follows: Install the prerequisite Windows Azure SDK Create an Azure project by right-clicking on your web project and choosing “Add Windows Azure Cloud Service Project” (or by manually adding that project type) Configure your Role and Service Configuration/Definition as desired Right-click on your azure project and choose “Publish,” create a publish profile, and push to your web role You don’t actually have to do step #4 and create a publish profile, but it’s a good exercise to make sure everything is working properly.  Once your Windows Azure project is setup correctly, we are ready to move on to understanding the Azure Publish process. Understanding the Azure Publish Process The actual Windows Azure project is fairly simple at its core—it builds your dependent roles (in our case, a web role) against a specific service and build configuration, and outputs two files: ServiceConfiguration.Cloud.cscfg: This is just the file containing your package configuration info, for example Instance Count, OsFamily, ConnectionString and other Setting information. ProjectName.Azure.cspkg: This is the package file that contains the guts of your deployment, including all deployable files. When you package your Azure project, these two files will be created within the directory ./[ProjectName].Azure/bin/[ConfigName]/app.publish/.  If you want to build your Azure Project from the command line, it’s as simple as calling MSBuild on the “Publish” target: msbuild.exe /target:Publish Windows Azure PowerShell Cmdlets The last pieces of the puzzle that make CI automation possible are the Azure PowerShell Cmdlets (http://msdn.microsoft.com/en-us/library/windowsazure/jj156055.aspx).  These cmdlets are what will let us create deployments without Visual Studio or other user intervention. Preparing TeamCity for Azure Deployments Now we are ready to get our TeamCity server setup so it can build and deploy Windows Azure projects, which we now know requires the Azure SDK and the Windows Azure PowerShell Cmdlets. Installing the Azure SDK is easy enough, just go to https://www.windowsazure.com/en-us/develop/net/ and click “Install” Once this SDK is installed, I recommend running a test build to make sure your project is building correctly.  You’ll want to setup your build step using MSBuild with the “Publish” target against your solution file.  Mine looks like this: Assuming the build was successful, you will now have the two *.cspkg and *cscfg files within your build directory.  If the build was red (failed), take a look at the build logs and keep an eye out for “unsupported project type” or other build errors, which will need to be addressed before the CI deployment can be completed. With a successful build we are now ready to install and configure the Windows Azure PowerShell Cmdlets: Follow the instructions at http://msdn.microsoft.com/en-us/library/windowsazure/jj554332 to install the Cmdlets and configure PowerShell After installing the Cmdlets, you’ll need to get your Azure Subscription Info using the Get-AzurePublishSettingsFile command. Store the resulting *.publishsettings file somewhere you can get to easily, like C:\TeamCity, because you will need to reference it later from your deploy script. Scripting the CI Deploy Process Now that the cmdlets are installed on our TeamCity server, we are ready to script the actual deployment using a TeamCity “PowerShell” build runner.  Before we look at any code, here’s a breakdown of our deployment algorithm: Setup your variables, including the location of the *.cspkg and *cscfg files produced in the earlier MSBuild step (remember, the folder is something like [ProjectName].Azure/bin/[ConfigName]/app.publish/ Import the Windows Azure PowerShell Cmdlets Import and set your Azure Subscription information (this is basically your authentication/authorization step, so protect your settings file Now look for a current deployment, and if you find one Upgrade it, else Create a new deployment Pretty simple and straightforward.  Now let’s look at the code (also available as a gist here: https://gist.github.com/3694398): $subscription = "[Your Subscription Name]" $service = "[Your Azure Service Name]" $slot = "staging" #staging or production $package = "[ProjectName]\bin\[BuildConfigName]\app.publish\[ProjectName].cspkg" $configuration = "[ProjectName]\bin\[BuildConfigName]\app.publish\ServiceConfiguration.Cloud.cscfg" $timeStampFormat = "g" $deploymentLabel = "ContinuousDeploy to $service v%build.number%"   Write-Output "Running Azure Imports" Import-Module "C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\*.psd1" Import-AzurePublishSettingsFile "C:\TeamCity\[PSFileName].publishsettings" Set-AzureSubscription -CurrentStorageAccount $service -SubscriptionName $subscription   function Publish(){ $deployment = Get-AzureDeployment -ServiceName $service -Slot $slot -ErrorVariable a -ErrorAction silentlycontinue   if ($a[0] -ne $null) { Write-Output "$(Get-Date -f $timeStampFormat) - No deployment is detected. Creating a new deployment. " } if ($deployment.Name -ne $null) { #Update deployment inplace (usually faster, cheaper, won't destroy VIP) Write-Output "$(Get-Date -f $timeStampFormat) - Deployment exists in $servicename. Upgrading deployment." UpgradeDeployment } else { CreateNewDeployment } }   function CreateNewDeployment() { write-progress -id 3 -activity "Creating New Deployment" -Status "In progress" Write-Output "$(Get-Date -f $timeStampFormat) - Creating New Deployment: In progress"   $opstat = New-AzureDeployment -Slot $slot -Package $package -Configuration $configuration -label $deploymentLabel -ServiceName $service   $completeDeployment = Get-AzureDeployment -ServiceName $service -Slot $slot $completeDeploymentID = $completeDeployment.deploymentid   write-progress -id 3 -activity "Creating New Deployment" -completed -Status "Complete" Write-Output "$(Get-Date -f $timeStampFormat) - Creating New Deployment: Complete, Deployment ID: $completeDeploymentID" }   function UpgradeDeployment() { write-progress -id 3 -activity "Upgrading Deployment" -Status "In progress" Write-Output "$(Get-Date -f $timeStampFormat) - Upgrading Deployment: In progress"   # perform Update-Deployment $setdeployment = Set-AzureDeployment -Upgrade -Slot $slot -Package $package -Configuration $configuration -label $deploymentLabel -ServiceName $service -Force   $completeDeployment = Get-AzureDeployment -ServiceName $service -Slot $slot $completeDeploymentID = $completeDeployment.deploymentid   write-progress -id 3 -activity "Upgrading Deployment" -completed -Status "Complete" Write-Output "$(Get-Date -f $timeStampFormat) - Upgrading Deployment: Complete, Deployment ID: $completeDeploymentID" }   Write-Output "Create Azure Deployment" Publish   Creating the TeamCity Build Step The only thing left is to create a second build step, after your MSBuild “Publish” step, with the build runner type “PowerShell”.  Then set your script to “Source Code,” the script execution mode to “Put script into PowerShell stdin with “-Command” arguments” and then copy/paste in the above script (replacing the placeholder sections with your values).  This should look like the following:   Wrap Up After combining the MSBuild /target:Publish step (which creates the necessary Windows Azure *.cspkg and *.cscfg files) and a PowerShell script step which utilizes the Azure PowerShell Cmdlets, we have a fully deployable build configuration in TeamCity.  You can configure this step to run whenever you’d like using build triggers – for example, you could even deploy whenever a new master branch deploy comes in and passes all required tests. In the script I’ve hardcoded that every deployment goes to the Staging environment on Azure, but you could deploy straight to Production if you want to, or even setup a deployment configuration variable and set it as desired. After your TeamCity Build Configuration is complete, you’ll see something that looks like this: Whenever you click the “Run” button, all of your code will be compiled, published, and deployed to Windows Azure! One additional enormous benefit of automating the process this way is that you can easily deploy any specific source control changeset by clicking the little ellipsis button next to "Run.”  This will bring up a dialog like the one below, where you can select the last change to use for your deployment.  Since Azure Web Role deployments don’t have any rollback functionality, this is a critical feature.   Enjoy!

    Read the article

  • run MsBuild tasks (targets?) after the solution is built?

    - by JoelFan
    Since this question seems to have baffled / underwhelmed SO I will rephrase it with a partially formed idea of my own. Could I somehow set up a batch file or something that runs after the whole solution is built, and this batch file would call msbuild to build specific targets inside a certain project? In order for it to work, I would have to somehow force msbuild build the target without regard to whether it thinks it's "up to date", because that is the core issue I'm butting up against.

    Read the article

  • How to make msbuild ItemGroup items be separated with a space rather than semi-colon?

    - by mark
    Dear ladies and sirs. Observe the following piece of an msbuild script: <ItemGroup> <R Include="-Microsoft.Design#CA1000" /> <R Include="-Microsoft.Design#CA1002" /> </ItemGroup> I want to convert it to /ruleid:-Microsoft.Design#CA1000 /ruleid:-Microsoft.Design#CA1002 Now, the best I came up with is @(R -> '/ruleid:%(Identity)'), but this only yields /ruleid:-Microsoft.Design#CA1000;/ruleid:-Microsoft.Design#CA1002 Note the semi-colon separating the two rules, instead of a space. This is bad, it is not recognized by the fxcop - I need a space there. Now, this is a simple example, so I could just declare something like this: <PropertyGroup> <R>/ruleid:-Microsoft.Design#CA1000 /ruleid:-Microsoft.Design#CA1002</R </PropertyGroup> But, I do not like this, because in reality I have many rules I wish to disable and listing all of them like this is something I wish to avoid.

    Read the article

  • Getting MSDeploy working on our build/integration server - Is an MSBuild upgrade necessary?

    - by Jeff D
    We have what I think is a fairly standard build process: 1. Developer: Check in code 2. Build: Polls repo, sees change, and kicks off build that: 3. Build: Updates from repo, Builds w/ MSBuild, Runs unit tests w/ nunit, 4. Build: creates installer package Our security team allows us to pull from the build server, but does not allow the build server to push. So we generally rdp in, d/l the installers, and run them, which rules out the slick deployment services, so I would need to generate packages instead. I'd like to use MSDeploy, except that we have the following issues: We're on .net 3.5, and the MSBuild target (Package) that uses MSDeploy requires 4.0. Is there anything I'd need to install other than .net 4.0 RC for this? (Would MSBuild be part of that upgrade?) When I generate packages with MSDeploy, I see that I don't have just 1 file. There's a zip, deploy.cmd, SourceManifest.xml, and SetParameters.xml. What are all the other files for, and why wouldn't they all be in the 'package'? It sounds as if you can create packages by telling the system to look at a working IIS site. But if the packages are build from a CI environment, aren't you basically out of luck here? It feels like they designed some of this for small-scale developers deploying from their dev environment. That's a fine use case, but I'm interested in see what everyone's enterprise-experience is with the tool Any suggestions?

    Read the article

  • VS2010 compiles solution without errors, msbuild fails: "fatal error CS0002: Unable to load message string from resources"

    - by Nathan Ridley
    I'm having a lot of trouble trying to track down the cause of this error message. I have a large Visual Studio 2010 solution which compiles without error on my local machine but on the build server, msbuild fails on one of the projects with the error: fatal error CS0002: Unable to load message string from resources Here's the red error section at the end: Build FAILED. "C:\TeamCity\buildAgent\work\85eff164854b9e67\Libraries\Domainface.Proxy.Common\Domainface.Proxy.Common.csproj" (default target) (9) -> (CoreCompile target) -> CSC : fatal error CS0002: Unable to load message string from resources. [C:\TeamCity\buildAgent\work\85eff164854b9e67\Libraries\Domainface.Proxy.Common\Domainface.Proxy.Common.csproj] 0 Warning(s) 1 Error(s) The entire msbuild output from the build server is here: http://pastie.org/3660842 What does the error generally refer to, that would cause it to build locally but not on the build server? UPDATE I have just run msbuild /version on both machines and it turns out the .net framework versions are very slightly different. Local machine is 4.0.30319.488 and build server is 4.0.30319.1. I'm about to run windows update on the server to allow it to install some updates, as several seem to be .net framework-related, so I'll see if that makes a difference. UPDATE Installing the updates didn't help. Just remembered I copied up csc.exe from the async preview a little while ago in order to facilitate async compilation (the actual async preview had failed to install on the server due to visual studio not being there, but installing visual studio team viewer seems to have fixed that, so i've just run the proper async ctp3 installer to see if that makes a difference.

    Read the article

  • What is the MSBuild equivalent to ant's -project-help?

    - by Jeremy Stein
    I come from an ant background, and I'm starting to use msbuild. I want to create a .proj file with targets for clean, compile, deploy, etc. In ant, I would expect my user to run ant -project-help to get a list of the targets with their descriptions. There doesn't appear to be anything like this with msbuild, so I was thinking of setting DefaultTargets to "Help" and adding this target: <Target Name="Help"> <Message Text="/t:Clean - Remove all bin folders and generated files"/> <Message Text="/t:Compile - Generate assembly"/> <Message Text="/t:Deploy - Install the assembly"/> </Target> When I run msbuild, I see this: Microsoft (R) Build Engine Version 3.5.30729.1 [Microsoft .NET Framework, Version 2.0.50727.3053] Copyright (C) Microsoft Corporation 2007. All rights reserved. Build started 5/13/2010 9:00:00 AM. Project "C:\MyProject\MyProject.proj" on node 0 (default targets). /t:Clean - Remove all bin folders and generated files /t:Compile - Generate assembly /t:Deploy - Install the assembly Done Building Project "C:\MyProject\MyProject.proj" (default targets). Build succeeded. 0 Warning(s) 0 Error(s) Time Elapsed 00:00:00.05 My target description are hidden among all the other output. It feels like I have a paradigm-mismatch here. What's the best way to provide the build functionality I want so that users know where to find each target?

    Read the article

  • Output redirection still with colors in PowerShell

    - by stej
    Suppose I run msbuild like this: function Clean-Sln { param($sln) MSBuild.exe $sln /target:Clean } Clean-Sln c:\temp\SO.sln In Posh console the output is in colors. That's pretty handy - you spot colors just by watching the output. And e.g. not important messages are grey. Question I'd like to add ability to redirect it somewhere like this (simplified example): function Clean-Sln { param($sln) MSBuild.exe $sln /target:Clean | Redirect-AccordingToRedirectionVariable } $global:Redirection = 'Console' Clean-Sln c:\temp\SO.sln $global:Redirection = 'TempFile' Clean-Sln c:\temp\Another.sln If I use 'Console', the cmdlet/function Redirect-AccordingToRedirectionVariable should output the msbuild messages with colors the same way as the output was not piped. In other words - it should leave the output as it is. If I use 'TempFile', Redirect-AccordingToRedirectionVariable will store the output in a temp file. Is it even possible? I guess it is not :| Or do you have any advice how to achieve the goal? Possible solution: if ($Redirection -eq 'Console) { MSBuild.exe $sln /target:Clean | Redirect-AccordingToRedirectionVariable } else { MSBuild.exe $sln /target:Clean | Out-File c:\temp.txt } But if you imagine there can be many many msbuild calls, it's not ideal. Don't be shy to tell me any new suggestion how to cope with it ;) Any background info about redirections/coloring/outpu is welcome as well. (The problem is not msbuild specific, the problem touches any application that writes colored output)

    Read the article

< Previous Page | 4 5 6 7 8 9 10 11 12 13 14 15  | Next Page >