I have the statements like following in my FSI scripts
#I #"C:\path\to\bin\Debug\myassembly.dll"
When I try to build the referenced dll again I get a
Unable to copy file "obj\Debug\myassembly.dll" to "bin\Debug\myassembly.dll". The process cannot access the file 'bin\Debug\myassembly.dll' because it is being used by another process.
I have tried closing FSI window, still no help. Any idea ?
I found the solution. Instead of closing the FSI window which preserves the state. I should have run #quit;; command.
Related
this is problem.
I developed a shell extension of Shell Context Menus.
(use SharpShell, enter link description here)
I can register it by using regasm.exe with "/codebase" attribute.
And without this attribute the shell extension doesn't work.
But this attribute let me can't update the .dll file without reboot explorer.
Even worse, can't delete .dll file after that unregistered and reboot PC (in windows 8).
So, did that have any way to solve this problem?
By the way, if anyone can tell me what is "/codebase" actually doing?
(I saw MSDN already, but totally can't understand.)
The only solution is to enumerate the handles created by explorer.exe and filter them by the target file, which is your own locked dll file. Then you can remove the handle.
It would require P/invoke if you will use C#, or handle.exe by Sysinternals if you will use any scripting language during installation. However, removing handles in the background of the application that has the handle is an unsupported way and may result with undefined consequences.
So in my TFS build, after the compile, I'm trying to copy some dlls over to the server. If they're currently in use, the build will fail.
Is there a way to force the overwrite, even if the file is open?
Thanks!
It's either a service or a desktop application accessing the dll file. You can find out what has access to the file using handle.exe from SysInternals.
Once you know what is accessing the dll file you can stop/kill it.
Moreover, there are also many other ways which can bypass the system prompts. However, it seems no one fit your situation. More ways to achieve force copy for you reference: How to copy "in use" files through batch file in Windows 7
I have a pre build event set up to generate the version/build number to embed in my exe. The event consists of a call to a batch file that does the actual work (a parameter is passed to the batch file). The batch file works as it should on all of the computers I've tried it on, including the Windows XP computers. It also runs fine as a pre build event on the 3 computers here running windows 7. The pre build event fails, however, on Windows XP. Delphi returns an error code that I can't seem to find a reference to anywhere, "20018".
I've tried a number variations to the way I call the batch file without any luck. Does anyone have an idea what's happening?
The build event is as follows:
call "..\..\Build Tools\PreBuild.bat" "$(PROJECTDIR)"
UPDATE:
I've removed the source of the batch file, since it had no relevance for the actual problem.
You gave so little information that I am tempted to vote to close. Instead I will venture a wild guess. You should post the commands in your post-build step.
If you don't know which line is failing, try the first one alone, and remove the rest, and see if that passes.
For example, I often have problems on XP machines using XCOPY commands in post-build steps, and these commands often result in really odd error codes that I am unable to diagnose or determine the meaning of. So if you have an XCOPY command, you should try the XCOPY inside and outside the build environment, and see if it works on that Windows XP box, for example.
You can copy the commands, as they are run, in their macros-expanded form, from the "Output" tab in the Rad Studio IDE, paste them into notepad, run them as a batch file, and try to figure out why they don't work on windows XP.
Here's an example of a workaround, using XCOPY. If this fails on XP, I tweak it till it works:
XCOPY SourceDir DestDir
I have had to fix it this way:
XCOPY.exe SourceDir DestDir
In another case, I found that I had to fix it this way:
call XCOPY SourceDir DestDir
You ALSO mention you are simply running a mysterious batch file and you fail to mention what it does. So let's see, what we could do differently to run a batch file from a post build step.... When I run a batch file like this, I sometimes have problems on XP, like this:
batchfilename.cmd
But when I run it differently, I find it worked on XP, but I lose the command line output:
call batchfilename.cmd
It seemed that something strange was happening when running post-build steps in the IDE, that could be resolved by trying the commands outside the IDE, in various forms.
The number (20018) you mention is a bit of a silly thing to go googling, it's probably the ERRORLEVEL (return value to the command shell) of whatever tool you are running in your batch file. Since you told us nothing about what tools you're running, I wonder if you have even done the basic step of looking at what happens when you run that batch file OUTSIDE the IDE on that XP machine. My guess is that if it didn't come from your own batch file, that it came from deep in the guts of MSBUILD itself, which is something that very few Delphi people will know the source code to (even the Delphi team itself is using a binary from Microsoft to provide MSBUild functionality). I notice that MSBUILD's built in tasks for doing post-build and pre-build steps are an area of the IDE that need improvement, especially when it comes to debugging problems like this. You can however, simply run them outside the IDE and see if they work that way, and you can try stuff, as I have suggested above.
If this is your batch file ... I suggest that due to dependency issues, you might not want to use such a batch file technique to modify an RC file, as it might expose some strange dependency issues in MSBUILD with RAD/Delphi build tasks. I have also seen some weird BRCC32 failures, on XP that I have not been able to reproduce.
Ok, I finally found the answer here:
http://delphi.about.com/od/devutilities/a/pre_post_build.htm
The problem was spaces in the path to the batch file being called. Apparently this isn't a problem in Windows 7.
Removing the space in the build tools directory and changing the pre build event to the following fixed the problem:
call ..\..\BuildTools\PreBuild.bat "$(PROJECTDIR)"
Here's the important bit from the link:
Command Line: This is the trickiest of them all, but after you get one working, they’re all easy. The trick here is not to use quotes on the program’s name but instead use the windows SFN (Short File Name). The reason is that, should you need to use quotes to enclose the path of your file, the IDE gets confused with too many quotes. So, these are the wrong ways of adding that command line above:
C:\Program Files\SoftwarePassport\Armadillo.exe D:\Dev\My Prog\Prot.arm /P
"C:\Program Files\SoftwarePassport\Armadillo.exe" D:\Dev\My Prog\Prot.arm /P
C:\Program Files\SoftwarePassport\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P
"C:\Program Files\SoftwarePassport\Armadillo.exe" "D:\Dev\My Prog\Prot.arm" /P
This last one should work, if it were not for the IDE to be confused with it. So, what does work is either of these:
C:\Progra~1\Softwa~1\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P
C:\Progra~1\SoftwarePassport\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P
When using F# interactive apparently this line of code will search in the path shown in the subject line.
let files = Directory.GetFiles("MyFolderPath")
Is there any way to set interactive to search the same folder the current fsx file is running from? Or any way to control this behavior at all? I'm used to the search starting in bin\Debug obviously and this behavior is throwing me off.
Thanks in advance,
Bob
It depends from where the process fsi.exe is started. Fsi is separated from the IDE, it doesn't know which file is open. When you run Visual Studio, the current directory for fsi is the temp folder.
If you run the fsx file (fsi foo.fsx or right-click "Run with F# Interactive"), fsi will run from current directory.
To see where you are (in which directory), you can do:
Directory.GetCurrentDirectory()
To change directory, use this command:
Directory.SetCurrentDirectory(...)
F# interactive is completely independent of the current F# program (in fact, think of it as running in a separate CMD shell). So I'm afraid, there won't be a simple way to get the currently opened .fsx file.
You might be able to pull something from fsi.CommandLineArgs but I have no VS at hand to confirm this.
I want to know if there is a way to start the PSUnitImporter.exe from command line. What I want to do is to have the import file created automatically as a Pre-Build Event.
So far I have found out that when running PSUnitImporter.exe "C:\folder\source.pas" it will invoke the Importer gui and automatically load the file. It will not do the conversion though and it shows the GUI which I don't want.
The gui itself isn't capable of doing that, however the source for the program is in svn at pascalscript project page. A few slight changes there will let you do what you want.
Thanks to CK who pointed me to the pascalscript projet page. I checked out the sourcecode there and found out that it already includes a project for a Commandline importer.
All I needed to do is compile this project and I was done. I wonder why this "CMDimp.exe" is not included in the Pascralscript setup.