I've been trying to get this re-build command working for a Windows 8 Project in Visual Studio 2012.
if "$(ConfigurationName)"==ReleaseOEM copy "$(ProjectDir)PackageOEM.appxmainfest" "$(ProjectDir)Package.appxmainfest" copy "$(ProjectDir)StoreManifestOEM.xml" "$(ProjectDir)StoreManifest.xml"
The xml file StoreManifest.xml is copied every time I do a rebuild; however the Package.appxmainfest is never changed.
What have I done wrong?
This worked in a test project ...
if "$(ConfigurationName)"=="Debug" copy "$(ProjectDir)Package.appxmanifest" "$(ProjectDir)Package2.appxmainfest"
The only real difference is I added quotes around Debug. It does not copy the file without the quotes. According to MSDN, you need to separate commands by line breaks. Yours should probably look something like ...
if "$(ConfigurationName)"=="ReleaseOEM" copy "$(ProjectDir)PackageOEM.appxmainfest" "$(ProjectDir)Package.appxmainfest"
if "$(ConfigurationName)"=="ReleaseOEM" copy "$(ProjectDir)StoreManifestOEM.xml" "$(ProjectDir)StoreManifest.xml"
Related
Not entirely sure why our script isnt backing up, i suspect that it may be something with the Robocopy. Ik robo copy is a sys32 file but looking at the script its shown to be apart of another path then followed by it is the correct path c:\windows\sys32.
So im looking at the two "copy "lines. lines 2&3. Is that normal formatting, because the robocopy is not in that path.
if exist "C:\windows\system32\robocopy.exe" Goto SkipPrep
copy"%logonserver%\netlogon\tools\robocopy.exe""C:\Windows\system32"
copy"%logonserver%\netlogon\tools\sleep.exe" "C:\Windows\system32\
cls
:SkipPrep
This a bat file
I have a CMake project and I need to copy files from one folder to another and do some additional renaming with the following pattern:
"xy-1" will be "abcd1",
"xy-2" will be "abcd2",
...,
"xy-123" will be "abcd123"
Currently I´m trying this with add_custom_command() and in general it works for a simpler pattern like
"xy-1" will be "abc1",
"xy-2" will be "abc2",
...,
"xy-123" will be "abc123",
I´m doing it with
COMMAND copy "${path_to_source_folder}xy-*.txt" "${path_to_destination_folder}abc*.txt"
In the working pattern the number of characters before the asterisk are the same for the source- and the destination-name.
But in the not working pattern, there are 3 characters in the source-name and four characters in the destination-name before the asterisk:
COMMAND copy "${path_to_source_folder}xy-*.txt" "${path_to_destination_folder}abcd*.txt"
This not working. There is no error coming from cmake, but it will not copy all files (only the first 99) and the names are not created properly.
A quick fix would be to list all (400+) files explicitly, but I´d like to avoid this ;-)
How to do this with add_custom_command() or if this is not possible, how to do it in another way?
Many thanks for your help!
Cheers Daniel
Upate:
Thanks for the hints in the comments! I´m running on Windows 10 and using powershell for running cmake.
I'm using sql developer.
I want to run some scripts.
I don't want to have to include the folder name in the call to each script.
But I also want to use a variable to include the directory to look in (the working directory).
I can do this but i am having trouble with folder names with spaces (this is in windows).
Can anyone help me work out how to do this without having to rename my folder to remove spaces?
define dir="c:\Users\xx\Google Drive\Analytics\Recruitment\NSL\2. Data Understanding\Code"
#&dir\cb_nsl_impairments.sql;
Returns error
SP2-0310: Unable to open file: "c:\Users\xx\Google.sql"
Oops. Solved it.
Just needed double quotes around the script call:
#"&dir\cb_nsl_impairments.sql"
I've done very little with batch files but I'm trying to track down a strange bug I've been encountering on a legacy system.
I have a number of .exe files in particular folder. This script is supposed to duplicate them with a different file name.
Code From Batch File
for %%i in (*.exe) do copy \\networkpath\folder\%%i \\networkpath\folder\%%i.backup.exe
(Note: The source and destination folders are THE SAME)
Example Of Desired Behavior:
File1.exe --> Becomes --> File1.exe.backup.exe
File2.exe --> Becomes --> File2.exe.backup.exe
Now first, let me say that this is not the approach I would take. I know there are other (potentially more straight forward) ways to do this. I also know that you might wonder WHY on earth we care about creating a FileX.exe.backup.exe. But this script has been running for years and I'm told the problem only started recently. I'm trying to pinpoint the problem, not rewrite the code (even if it would be trivial).
Example Buggy Output:
File1.exe.backup.exe
File1.exe.backup.exe.backup.exe
File1.exe.backup.exe.backup.exe.backup.exe
File1.exe.backup.exe.backup.exe.backup.exe.backup.exe
File1.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe
File1.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe
etc...
File2.exe.backup.exe
File2.exe.backup.exe.backup.exe
File2.exe.backup.exe.backup.exe.backup.exe
File2.exe.backup.exe.backup.exe.backup.exe.backup.exe
File2.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe
File2.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe.backup.exe
Not knowing anything about batch files, I looked at this and figured that the condition of the for statement was being re-evaluated after each iteration - creating a (near) infinite loop of copying (I can see that, eventually, the copy will fail when the names get too long).
This would explain the behaviour I'm seeing. And when cleaned the directory in question so that it had only the original File1.exe file and ran the script it produced the bug code. The problem is that I CANNOT replicate the behaviour anywhere else!?!
When I create a folder locally with a few .exe files and run the script - I get the expected output. And yes, if I run it again, I get one instance of 'File1.exe.backup.exe.backup.exe' (and each time I run it again, it increases in length by one). But I cannot get it to enter the near-infinite loop case.
It's been driving me crazy.
The bug is occurring on a networked location - so I've tried to recreate it on one - but again, no success. Because it's a shared network location, I wondered if it could have something to do with other people accessing or modifying files in the folder and even introduced delays and wrote a tiny program to perform actions in the same folder - but without any success.
The documentation I can find on the 'for' statement doesn't really help, but all of the tests I've run seem to suggest that the in (*.exe) section is only evaluated once at the beginning of execution.
Does anyone have any suggestions for what might be going on here?
I agree with Andriy M's comment - it looks to be related to Windows 7 Batch Script 'For' Command Error/Bug
The following change should fix the problem:
for /f "eol=: delims=" %%i in ('dir /b *.exe') do copy \\networkpath\folder\%%i \\networkpath\folder\%%i.backup.exe
Any file that starts with a semicolon (highly unlikely, but it can happen) would be skipped with the default EOL of semicolon. To be safe you should set EOL to some character that could never start a file name (or any path). That is why I chose the colon - it cannot appear in a folder or file name, and can only appear after a drive letter. So it should always be safe.
Copy supports wildcard characters also in target path. You can use
copy \\networkpath\folder\*.exe \\networkpath\folder\*.backup.exe
The Story So Far
I've got a nice solution with a desktop application project, a few library projects, and a couple of development tools projects (also desktop applications). At the moment, my build server outputs all of the code into one OutputPath. So we end up with
drop-x.y.z\
Company.MainApplication.exe <-- main application
Company.MainApplicationCore.dll <-- libraries
Helper.exe <-- developer tools
Grapher.exe
Parser.exe
... <-- the rest of the output
But, we're growing up and people outside of our team want access to our tools. So I want to organize the output. I decided that what we would want is a different OutputPath per executable project
drop-x.y.z\
Company.MainApplication\
Company.MainApplication.exe <-- main application
Company.MainApplicationCore.dll <-- libraries
... <-- application specific output
Helper\
Helper.exe <-- developer tools
... <-- tool specific output
Grapher\
Grapher.exe
...
Parser\
Parser.exe
...
What I Did
I found this simple command. I like it because it retains all the Solution working-dir context that makes msbuild a pain.
msbuild /target:<ProjectName>
For example, from my solution root as a working directory, I would call
PS> msbuild /target:Helper /property:OutputPath="$pwd\out\Helper"
I'm testing this from PowerShell, so that $pwd resolves to the full path to my working directory, or the Solution root in this case. I get the output I desire.
However, when I run this command
PS> msbuild /target:Company.MainApplication /property:OutputPath="$pwd\out\Company.MainApplication"
I get the following error output (there's no more information, I ran with /verbosity:diagnostic)
The target "Company.MainApplication" does not exist in the project.
What I Need
The command fails on any project with a dot or dots in the name. I tried with many combinations of working directories and properties. I tried several ways of escaping the property values. I also tried running the command from a <Task> in a targets file.
I need to know either
A) How to fix this command to work property
B) How to achieve the same output with minimal friction
Try using an underscore as an escape character for the dot in the target parameter, e.g.
msbuild /target:Company_MainApplication /property:OutputPath="$pwd\out\Company.MainApplication"
Specify the target after the -target: switch in the format :. If the project name contains any of the characters %, $, #, ;, ., (, ), or ', replace them with an _ in the specified target name.
https://learn.microsoft.com/en-us/visualstudio/msbuild/how-to-build-specific-targets-in-solutions-by-using-msbuild-exe?view=vs-2019
Dan Nolan's answer and comments are correct. Just want to supplement the Microsoft documentation.
The /targets: switch is to identify a <Target to run in the project file. You need to supply your .csproj file as a an argument that is not prefixed by a /xx option marker.
You might also want to work based on the .sln file. In that case, you still dont specify the project in the .sln to build in this manner. I'll leave you to search up the correct syntax in case that's what you end up doing.