With TFS Build 2010, I have build process running devenv.com for several projects. After that, I want all the binaries to be copied from the output folders with C# Custom Build Activities with "File.Copy". However, it threw me this exception with the first copy of the file:
The process cannot access the file 'C:\Test\BuildServer\Sources\Library\LibraryInstall\LibraryInstall\Release\LibraryInstall.msm' because it is being used by another process.
It seems the file is still been using by the devenv.com. Any idea how? Other than File.Copy, is there any better way to copy it regardless the file status?
======
I found an ugly way:
Process proc = new Process();
proc.StartInfo.UseShellExecute = true;
proc.StartInfo.FileName = #"C:\WINDOWS\system32\xcopy.exe";
proc.StartInfo.Arguments = "/Y " + Path.Combine(sourcesDirectory, fileName) + " " + binariesDirectory;
proc.Start();
Devenv is an agressive file locker. If you can build your projects by creating an MSBuild file and bypassing devenv you'll be better off. Some project types can only be built with devenv though, you've not specified what project types you are using so this may not be an option.
MSBuild has a feature called "node reuse" whereby it creates processes that can hang around for up to 15 minutes as an optimization for subsequent builds. It may be that the node reuse combined with devenv's file locking behavior is giving you trouble.
You've not made it clear just exactly how you are executing your build, but if MSBuild is involved, you could try to specify the /nodereuse:false option to disable this feature.
I've also seen rogue MSBuild and devenv process hang onto files, they can get hung up and stay around forever until you kill them if there are obscure exceptions in your build.
I have few amateur things. Don't put a minus on my answer =)
First, take a look at this answer to change your algorithm little bit
You can create batch file which includes same ugly method in
it. Then call this batch file from C#
Maybe you can use FileStream.. binary read-write
Maybe you can import vb referance to your project and use ( non-sense
)
Or directly kill the process which accourding with this error.
And here is an another search, please take a look this question too.
This is the last and hard-core long shot.
Best Regards...
Related
I have this method
private void StartSDCBackupSet() {
using (Process p = new Process()) {
p.StartInfo.FileName = "SDCBackup";
try {
p.Start();
BackIcon.ShowBalloonTip(5000, "Backup", "Editor for settings startet", ToolTipIcon.Info);
} catch (Exception) {
MessageBox.Show("Program til settings blev ikke fundet");
}
}
}
According to the documentation I can find - and quite a lot of answers here -, it should start another program - SDCBackup.exe.
It doesn't. And I HAVE tried adding the .exe to the filename, but it does not make a difference. I get the messagebox with the message...
I have checked p and StartInfo and everything looks right. StartInfo.UseShellExecute is true.
Debugging reveals, that it is the line p.Start(); that produces the exception. And the Exception is a System.ComponentModel.Win32Exception with message:
File not found
Documentation says, that the code above does the excat same thing as Run in Windows menu, but it obviously does not.
If I write SDCBackup in the RUN section of Windows menu, SDCBackup.exe is started as it should.
(And SDCBackup.exe is a ClickOnce installation, that nobody really knows where to find - other than Windows itself...)
So why does my code not do the trick?
Use
p.StartInfo.FileName = "SDCBackup.exe";
Windows tests out known file types, and if it's an .exe (or any other known type, such as .bat, msc, scr, etc.) it runs it. As far as I know .NET does not do that.
You could try using Path.GetFullPath (https://msdn.microsoft.com/de-de/library/system.io.path.getfullpath(v=vs.110).aspx) but I think it should work with relative paths as well.
Also make sure the file is inside your debug/release folder (whatever folder your .exe that is starting SDCBackup is in), since Windows looks in known directories that are contained in the PATH variable (such as C:\windows\System32, etc), and .NET does not. If it is not in that folder, provide a fully qualified path and it should work.
It seems no one knows how to reference a ClickOnce installed application in another application. (Asked the question at Microsoft, and got no useful response there either.)
It seems ClickOnce apps are installed somewhere in the current users area, e.g.:
C:\Users\[user]\AppData\Local\Apps\2.0
and from there 3 randomly named folders down - and not the same folder names for different users; so there seem to be no way to solve this.
But I did get a way to create a regular installer from Microsoft, for Visual Studio C# solutions.
I used it to set the install path of my apps, so they can find it each other - and it functions.
Install projecttype Installer
and follow the explanation
It involves adding a Installer project to the solution.
I found, that in addition to the explanation,
you have to go to Options for the installer-project,
select **"Configuration Manager",
and set it to be included when building
I also found, that version control is not automatic. You must manually set version number - and for the sake of simplicity, this is a different format than the one Visual Studio uses. If you do set the version, it will automatically uninstall previous versions of the same app.
I have both VS2010 and VS2013 installed and am trying to run a program that compiles a .net 4.0 solution by calling MSBuild (C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319).
For the record, the code that does this looks like:
var processStartInfo = new ProcessStartInfo
{
FileName = pathToMSBuild,
Arguments = "C:\path\to\mySolution.sln /nr:false",
CreateNoWindow = true,
UseShellExecute = false
};
var process = Process.Start(processStartInfo);
process.WaitForExit();
I've checked the .sln, which contains a .vcxproj and .csproj file, and these only contain references to ToolsVersion=4.0.
When I execute the program in VS2010 (or open cmd.exe and run the MSBuild command myself) it works fine and compiles the solution. However, when I run the same program using VS2013 I get the following error from MSBuild:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\CodeAnalysis\Micros
oft.CodeAnalysis.targets(214,5): error MSB4175: The task factory "CodeTaskFacto
ry" could not be loaded from the assembly "C:\WINDOWS\Microsoft.NET\Framework64
\v4.0.30319\Microsoft.Build.Tasks.v12.0.dll". Could not load file or assembly '
file:///C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Build.Tasks.v
12.0.dll' or one of its dependencies. The system cannot find the file specified
. [C:\...\solution\myProject.vcxproj]
I found this answer on msdn that actually solved this for me - after commenting out the offending lines from this file, I can call MSBuild succesfully from VS2013. But I don't understand why this is relevant since I thought I was running a v4.0 MSBuild to compile a project with ToolsVersion=4.0.
Presumably this is due to some environment variable getting set when I run/debug my program with VS2013? I can't find any details on the internet. Please could someone explain what is going on here?
You could try adding the /v:diag switch to your arguments. This will cause msbuild to run with output verbosity set to diagnostic. This will show you the state of env vars and the app domain at the start of each call and might help you to identify differences.
Note - take this out when you're done as it will significantly slow down the build process.
Problem
The error is a Could not load file or assembly and The system cannot find the file specified .. .vcxproj:
Troubleshooting
Open ProcessMonitor and run the build process until it throws the error. Stop the trace when it fails and investigate ProcMon's (Filemon) log to see where the MSBuild is looking for the .vcxproj or .xyz files/assemblies it cant find. Solve that!!
Solution
Put the file where its expected to be found.
I am building a C# adding for Excel. In order to debug it, I need to launch Excel.exe with a command line argument containing the Debug or Release path to the addin.
For example:
Start External Program: C:\Program Files\Microsoft Office\Office15\EXCEL.EXE
Command line argument "C:\Dev\Project1\Project1\bin\Debug\Project1-AddIn64.xll"
However, I would like to replace "C:\Dev\Project1\Project1\bin\Debug" with an equivalent of $(SolutionDir) for C++ projects in VS. Is there a way to do this ? If it is not doable, is there a way to get around this ?
EDIT: please support me and get this added in VS by voting up the following idea: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6350738-support-for-macros-in-debugging-command-line-argum
Indeed, the macros cannot be used in the Start Options | Command line arguments
I see two solutions:
As the current folder is set to the $(TargetDir) when you Start an application you could refer to the solution folder like this: ..\..\..\ if the External program accepts a relative path. (I am not quite sure why you would ever want to refer to the solution folder, referring to the output/target folder makes more sense to me)
In the Post Build event (unregister) and register the component the way the component should be registered when deploying it (a proper setup). This way you only have to refer to Excel in the Start Action. This also immediately adds the benefit of testing a scenario that is more similar to production.
It's not exactly a fix, but this may help some people. If you create your project from the project template "Visual C#/.NET Core/Console App" instead of "Visual C#/Windows/Console App", this feature is supported. When I put "$(SolutionDir)" in the Application Arguments field on the Debug tab of the Project Properties window, it is expanded at run time. Note that you will need Visual Studio 2015 Update 3 or later.
I guess you could make use of post-build event to read in your file. #HansPassant explained it in VS2010 - Project Macro Variables in Start Options Command Line Arguments.
A short quote:
A possible workaround is a post-build event that writes a file that you read in your program. Like echo $(ProjectName) > "$(TargetDir)cmdargs.txt
You could substitute cmdargs.txt to appropriate file you want.
You CAN use the macros in the Command fields. I used procmon.exe to see what VS was looking for and indeed i could use $(SolutionDir)\..\Debug\thetoolname.exe as my solution was not in the root.
Im using VS2019 so AFAIK it is supported from this version but it most likely is supported in lower versions. Just use procmon to check the path that VS is attempting to resolve.
For past few days, I had been struggling with Merging assemblies inside a single executable file. So that I can distribute the single executable file to my users. I found out ILMerge to do this apart from ILMerge, there are few more tools that seem to do it. I tried BoxedAPP Packer and SmartAssembly also .NetShrink seems to work good but all are paid tools. So, I wanted to complete the task with ILMerge and after much of browsing and searching Google and from StackOverflow, I found out the solution.
I tried the below set of lines for merging the assembly
c:\"Program Files"\Microsoft\ILMerge\ILMerge.exe"
/lib:"C:\Windows\Microsoft.NET\Framework\v3.5"
/lib:"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies"
/t: winexe
/target:exe
/targetplatform:v3.5,C:\Windows\Microsoft.NET\Framework\v3.5
/out:”MergedProduct.exe”
"$(TargetDir)Product.exe"
"$(TargetDir)CButtonLib.dll"
"$(TargetDir)Common Tools.dll'
"$(TargetDir)Core.dll"
"$(TargetDir)ProgressIndicator.dll"
"$(TargetDir)TaskScheduler.dll"
I used this above set of lines inside
Build-Events > Post-Build event command line
and after building the project I got as build succeeded. Also while building the application runs as if i have pressed F5 to start debugging. So, to summarize up, I'm sure the above set of lines are correct but i couldn't find the output executable file (i.e MergedProduct.exe) anywhere. I also tried using the Release mode of the Visual Studio 9.0 but still i couldn't find the Output merged executable.
Is there something really obvious that i'm missing?
Also, can I merge Product.exe.config file using ILMerge?
Any help or suggestions would be really appreciated.
Is that codeblock a cut and past of the command line? I notice you have fancy quotes around the /out filename. Also, have you tried adding a folder to the /out filename (eg, $(TargetDir))? We do that in our build process to save it in a particular publish folder.
ILMerge will allow you to merge the xml documentation, but not the configuration files (as far as I'm aware).
My dilemma is that I need to compile a large amount of projects and solutions as per the configuration settings specified in the files. I've found a few different ways to do this, and I've landed on using the Microsoft.Build.BuildEngine.Engine class, which has recently become deprecated.
Here's some sample code that illustrates its use: (note that node.Path is the path to the project file)
var builder = new Engine { BinPath = #"C:\Windows\Microsoft.NET\Framework\v3.5" };
var logger = new FileLogger { Parameters = #"logfile=" + Path.Combine(logdir, Path.GetFileName(node.Path)) + ".txt" };
compiler.RegisterLogger(logger);
bool success = compiler.BuildProjectFile(node.Path);
compiler.UnregisterAllLoggers();
return success;
My problem - it compiles in debug :(
Looking through the members of the class hasn't helped much as there aren't that many properties exposed. The one hint was the PropertyGroup property which seems to allow the setting of some project build options.. however it isn't clear how to get the resulting call to BuildProjectFile to output in release.
I'd really appreciate any help with this!
Do you have to do this through code? You may find it easier to use something like NAnT, along with NAntContrib, the MSBuild task is fairly comprehensive and makes it quite easy to specify which target to build, for example:
<msbuild project="${ProjectBasePath}\${ProjectName}.sln">
<property name="Configuration" value="debug"/>
</msbuild>
You can also call MSBuild from the command line, for example:
msbuild.exe project.proj /t:rebuild /p:Configuration=Debug
The advantage nant would give you, over msbuild is that you can script your build process. I, personally, find it quite easy to get on with and you can get a lot of power and flexibility out of it.
You can also call Visual Studio directly:
devenv.exe /Rebuild release "ProjectName.sln" /Out "c:\vs_errors.txt"
This will also output build output to c:\vs_errors.txt
I don't understand why you need to constantly compile. Settings files as you mention should be in app.config or web.config (depending it's a webservice). Settings files should not change the compilation of the app code. If it is I suggest you change your Programming model to allow for changing settings without recompiling.