I'm running a batch file from Visual Studio during the AfterPublish event. I'm doing a file system publish, and having trouble with the second parameter as in:
<Exec Command="$(SolutionDir)\PostBuildEventPublish.bat "$(ProjectDir)" "$(ProjectDir)"" />
I really need the second parameter to point to the output path where I specified to publish to. The above line works now since I wanted to test if the batch file was working in the first place but now I need the batch file to work against where I'm publishing to.
Thanks much for any help
See this answer: How to pass command line parameters to a bath file?
If you are passing the parameters in the right way, then maybe there is a problem with your bath code.
Related
I'm diagnosing a Visual Studio project building problem, and I want to see what MSBuild.exe actually does. However, from Procmon, I see MSBuild creates BAT file, call it and delete it immediately, then how can I see that BAT's content?
For example, real BAT command is hidden inside tmpd60d571fd9d549e5b2b31bb1f2ba51a7.exec.cmd.
"C:\Windows\system32\cmd.exe" /Q /C C:\Users\win7evn\AppData\Local\Temp\tmpd60d571fd9d549e5b2b31bb1f2ba51a7.exec.cmd
MSBuild.exe writes cl.exe, link.exe, Prebuild/Postbuild custom commands etc into those temporary bat files. Specifically, I want to see how exactly MSBuild is calling my custom commands and how does he pass parameters to me from within a bat file.
The ideal way, I think, may be some tools that can intercept file deleting operation, and make a backup(copy) of that file, so we can investigate the "deleted" files later. Procmon only records ReadFile and WriteFile byte count, but not their byte content, so I think Procmon is not enough.
==== Update ====
According to stijn's answer(env-var MSBUILDPRESERVETOOLTEMPFILES=1), I tried it on VS2019 with success. The content in the xxx.exec.cmd is like this:
Two things to note:
We don't need to pass /verbosity:d parameter.
On VS2010, the MSBuild version may be too old, no effect.
Final comment: I think this feature of "seeing true .bat content" is critical, because, I may use many macros in my Custom-build/Prebuild/Postbuild commands, like $(ProjectDir), $(Configuration), or even my own defined macros of any name, so I need a global view of the macro expansion result, instead of checking each macro from VSIDE UI one by one(so many mouse clicking and time consuming) . The .bat content is the exact global view I need.
Msbuid creates .cmd files when it runs the Exec task, depending on what problem you are diagnosing it might be enough to just know what statements are added in those files, which can be found here: https://github.com/dotnet/msbuild/blob/main/src/Tasks/Exec.cs.
Otherwise set the MSBUILDPRESERVETOOLTEMPFILES environment variable to 1 so the files do not get deleted, then run with /v:D to see which files were created.
I have the following need:
I'll have to create an MSBuild task that will produce an xml file, which I then need to embed as a resource to one of the projects being built. How do I change my MSBuild proj to accomplish that? Is there a built-in task I can use for embedding the file, or do I need to create one? If the latter, any direction on that would be great.
Thanks in advance!
Update: based on the suggestions given, I've ended up adding an empty xml file to the project as a resource, creating a simple MSBuild custom task (http://bartdesmet.net/blogs/bart/archive/2008/02/15/the-custom-msbuild-task-cookbook.aspx) that writes content to that file as I need it, and running that task as a "BeforeBuild" target. Works like a charm. Note that I've had to "exclude the file from source control", so it won't get checked out every time I build the project, and I've also added some code to the task to make sure the file isn't read-only (http://www.del337ed.com/blog/index.php/2007/09/05/clearing-the-read-only-flag-on-a-file-in-c/).
If you don't need to create the whole Xml file from scratch and could add a stubb file to your project you could use the XmlPoke Task to update this file in the BeforeBuild Target (see Sergios answer).
You can use builtin in your .csproj/.vbproj file target BeforeBuild (not forget to uncomment it) and call required MSBuild task in BeforeTarget. In that project add that resource as embedded. That's all.
Does anyone know how to get hold of the path to the directory where the LINQPad script file (.linq) resides?
Or to the script itself for that matter.
Note that I'm not talking about the location of the "My Queries" folder, the one shown inside LINQPad.
I can save a .linq file anywhere on disk, and open it by double-clicking on it.
For instance, if I save the file to C:\Temp\Test.linq, and execute the program, I'd like to have either C:\Temp or C:\Temp\Test.linq.
Basically I'd like something akin to Environment.CurrentDirectory or Assembly.GetEntryAssembly().Location, just for the .linq file.
Things I've tried:
Looking through environment variables
Looking through the LINQPad assembly that is given to my script
Throwing an exception and looking at the stacktrace (contains a link to a temporary copy of my script somewhere else)
Environment.CommandLine.Dump(); - gives LINQPad executable
Environment.CurrentDirectory.Dump(); - gives C:\windows\system32
Assembly.GetExecutingAssembly().Location.Dump(); - gives temp directory
I've just added a feature to address this. You can test it now by downloading the 2.27.1 or 4.27.1 beta build.
To get the current query's folder, use the following expression:
Path.GetDirectoryName (Util.CurrentQueryPath)
I presume you mean programatically and not through the UI itself.
The path to the linq file directory is held in
%APPDATA%\LINQPad\querypath.txt
The next question after "How do I get LinqPad script directory" is "How do I set it?" below is how you do it and link to where I found the answer
Directory.SetCurrentDirectory (Path.GetDirectoryName (Util.CurrentQueryPath));
I have a program with an associated file type. However, when I double-click a file to launch the program, I can't figure out where that path was passed to the program.
Initially I thought the file path would be in Environment.CommandLine, but the command line only contained the program path.
I specified the file association using the Publish Options in visual studio like so: extension: .ext, Description: Some File, ProgId: ProjectName, Icon: SomeIcon.ico.
You are right, it should indeed be passed as a command line argument and be available through Environment.CommandLine.
My guess is that something is wrong with the file association itself. Here is a dated but still useful TechNet article on how these things work. In particular, the "%1" in the screenshot below is essential.
I'm not sure about the DDE thing, so if you're not using it, turn it off.
As a guess, your file type association may not be configured properly. If you look in the registry at your "Open" command for your file type, the command is probably configured as "c:\your-company\your-app.exe", instead of as "c:\your-company\your-app.exe" "%1", which is what it would need to be if you wanted the file path to show up on the command line.
I'm trying to use the VssGet task of the MSBuild Community Tasks, and the error message "File or project not found" is beating me with a stick. I can't figure out what in particular the error message is referring to. Here's the task:
<LocalFilePath Include="C:\Documents and Settings\michaelc\My Documents\Visual Studio 2005\Projects\Astronom\Astronom.sln" />
<VssGet DatabasePath="\\ofmapoly003\Individual\michaelc\VSS\Astronom_VSS\srcsafe.ini"
Path="$/Astronom_VSS"
LocalPath="#(LocalFilePath)"
UserName="build" Password="build"
Recursive="True" />
If I write a Streamreader to read to either the database path or the local path, it succeeds fine. So the path to everything appears to be accessible. Any ideas?
Two thoughts. One, sometimes a type load exception manifests as a FNF - let's hope that's not it. But if the code is actually being honest, you can track the problem using Procmon or Filemon. Start one of those utilities and then run your task again. You should be able to track down a record of a file that couldn't be located.
#famoushamsandwich that's a great response -- I had not previously heard of procmon or filemon. Tried procmon on the problem, but even after sifting through the relevant output (my gosh the machine does a lot more stuff behind the screen than I was aware of) I couldn't find where a file I'm referencing wasn't being found.
Procmon and Filemon are good suggestions - just make sure you filter the results to only show errors. Otherwise the success messages will bury the problem entries. Also, you can filter out processes that are not at fault (either through the filter dialog or by right-clicking the entry and choosing "Exclude Process".)
A couple other thoughts:
In the LocalFilePath, you are specifying a single file as opposed to a folder. The task, on the other hand, specifies to get files recursively. Perhaps you need to remove "\Astronom.sln" from the LocalFilePath?
Is the build task being run under your account or another? It's possible you have a permissions issue
Do you already have a copy of the code pulled down in the same location? Perhaps there is a failure to overwrite an existing file/folder?