I just setup hudson (CI), how do I tell this Dude that my NAnt.exe is not in the \bin folder?
it's keep looking for this path:
C:\myProjects\web2009\tools\nant\bin\NAnt.exe //doesn't exist
but in the reality I setup it, in here:
C:\myProjects\web2009\tools\nant\NAnt.exe // the correct path
Have you looked at the Hudson configuration page? It should be configurable there:
http://hudson:8080/configure
The Nant plugin has a wiki page which says in part:
In order to use this plugin, you need to first
configure a NAnt installation, which can be done on
the Hudson Configuration page. Simply specify a name
for the installation, and the path to the installation
directory.
The Wiki Page answer to simply specify a name and path is NOT enough.
It seems that the installation path for the NANT HOME makes an "assumption" that there is a further \bin folder where the actual EXE is located. We all know what happens when you make an assumption.
So, for example:
My nant was located in
C:\Code\Projects\Learning_Hudson\tools\nant
and I kept getting errors, even though that was the same path I used in my NANT HOME config value. But I did keep getting a "not a directory" error on my NANT HOME with the above path.
So, after searching for an answer, which I didn't find, I found this question and it helped me figure out to MOVE my nant files to a bin subdirectory.
C:\Code\Projects\Learning_Hudson\tools\nant\bin - is where I moved the nant files
and the I left the NANT_HOME configuration path as
C:\Code\Projects\Learning_Hudson\tools\nant
and that got ride of the errors, and I finally got a successful build after 12 attempts, and lots of configuration changes.
Hudson seems to expect NANT_HOME to point to a folder that contains a bin directory where nant.exe can be found.
This confused me as well at first, but I just moved my Nant\bin folder to the appropriate location to get Hudson to save the setting. (I'd imagine you can do the same thing to get your setup working.)
Related
I am using Conan package manager on Windows to create a package. The conan command to create the package copies files to a folder within %USERPROFILE%\.conan (or C:\Users\xxxxxxx\.conan). Then from this location it builds a Visual Studio project and ultimately calls doxygen.exe to create a .chm help file in a post-build command. The doxygen command fails with:
error : failed to run html help compiler on index.hhp
Further investigation reveals the hhc.exe command executed by doxygen is failing with:
C:\Users\xxxxxxx\.conan\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation>"C:/Program Files (x86)/HTML Help Workshop/hhc.exe" html\index.hhp
HHC5010: Error: Cannot open "C:\Users\xxxxxxx\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation\html\Module.chm". Compilation stopped.
Close inspection reveals that in the error message, the ".conan" folder is missing. Sure enough, I confirmed that hhc.exe fails when the index.hpp resides in a folder that has a parent folder that starts with a ".".
Attempts to resolve this:
changing the Doxyfile setting OUTPUT_DIRECTORY to "$(TMP)/DoxygenModule" resolves the error, but creates the .chm file in another location, which I do not prefer.
navigating to the 8DOT3 name of the ".conan" folder, which is "CONAN~1", to run the hhc.exe command, succeeds, but unfortunately I have no way of getting conan to use this 8DOT3 path for creating the package. E.g. C:\Users\xxxxxxx\CONAN~1\...
I can live with the using the %TMP% folder but would prefer generating the .chm in the current folder. Anyone have any ideas?
HTML Help Workshop v1.31 is installed on my machine at C:\Program Files (x86)\HTML Help Workshop, probably from a Visual Studio installation (not sure). I attempted using a version downloaded from Microsoft website (v1.30) as well, which made no difference.
Other info: Conan version 1.18.0, Doxygen version 1.8.14, Windows 10 Version 1809
Unfortunately not a solution, but this is a known limitation in the hhc.exe, see: https://social.msdn.microsoft.com/Forums/en-US/0681145c-223b-498c-b7bf-be83209cbf4e/issue-with-html-workshop-in-a-windows-container?forum=visualstudiogeneral
HTML Help 1.x command line compiler hhc.exe cannot compile CHM file to folder whose full path contains folder name starting with dot. If you have that problem, you probably specified output path with folder starting with dot, e.g. "d:\My files.NET\documentation". You can use dots in folder names but not at the beginning.
Edit 2019-11-15:
I've just pushed a proposed patch to github (pull request 7402, https://github.com/doxygen/doxygen/pull/7402).
This proposed patch changes inside doxygen from the current directory to the short named current directory, but just for the HTML Help compilation.
Edit 2019-11-16:
Code has been integrated in the master version on github.
This is not an answer either. Actually, you found the answer and workaround[s] yourself.
Use OUTPUT_DIRECTORY to specify a directory containing no folder names beginning with periods.
The error you described is a known issue of the MS HTML Help compiler. More general, the HTML Help compiler does not like some folder and file names. Try and stick with these characters _, a..z, A..Z, 0..9. Do not use these signs in particular ., -, # .
Please note that the proprietary CHM file format is about 20 years old (Windows 95, ...). HTML Help is in maintenance mode, which means no new features and bug fixes are expected for either the runtime or the compiler. All mainstream development on HH has stopped.
There is no way to avoid this error if a directory name above begins with a period. Not even if only the necessary files are written by Doxygen and compiling of the index.hhp is done by a third-party tool like FAR HTML using your path that contains .conan. This is because all applications are using the faulty HHA.dll.
The above applies of course to the entire workflow you have described. Maybe you can interrupt it.
Doxygen can be configured not to call the HTMLHelp compiler. Just uncheck the GENERATE_HTMLHELP option (DoxyWizard: Experts > Topics > HTML). You have all files generated by Doxygen in your preferred output directory - but of course without the CHM file. This can be imported later e.g. by HelpNDoc and compiled as a CHM file in another location.
If you can interrupt the workflow and can also make changes to Doxygen's settings, then a preference setting of OUTPUT_DIRECTORY to e.g. C:/CacheMenu/CONAN~1/DOXYGE~1 also works as expected (here used as test case).
No matter what you do, your workaround and copy and paste from another directory outside is a quick solution at this stage. Please note the EDIT in #albert's answer.
I'm using PyDev in a django project of mine.
When I start the django sheel, the os.getcwd() command returns my home folder.
This is bad, since my code points to some resources by relative paths, assuming as current directory the directory containing the manage.py.
In this post (http://stackoverflow.com/questions/2746342/pydev-and-django-pydev-breaking-django-shell) someone recommended to use absolute paths to avoid this problem.
But I think it is a very bad practice, since things will not work when other people checkout the code into their computers.
The closest hint I found here:
http://old.nabble.com/-pydev---Users--how-to-set-working-directory-for-console--td25328455.html
It seems we can use "Run/Debug Settings" to set the current directory associated to a "runnable module". However, in this way we cannot associate the setting to the django console. I have tried to associate it with the manage.py, but it did not work.
So, the question: how to define the working directory of django shell?
Thank you,
Leonardo
I got a problem with MSTest Deployment,
i set folder deployment to something like that "..\MyProject\bin\debug\"
I know this path is relative to the test solution dir (C:\dev\MyApplication\Tests in my case) and it appears as
>Solution Directory>..\MyProject\bin\debug\ in the deployment GUI.
The problem is that there is no error at all but no folder or files are copied.
But if i put the full path like this
C:\dev\myApplication\MyProject\bin\debug\
i got a warning that it could not work on other computers as it's outside the solution folder.
despite that warning it works and all files from my debug folder are copied.
The problem is that i want relative pathes as every one on the team got a root path of the solution different of course.
Any Idea ???
I forgot to mention that this project was migrated from VS2008 where it worked to vs2010 where i have this problem.
The relativeroot is by default the solution directory. So this should be "MyProject\bin\debug\"
I keep getting this NAnt error, please advise...
The type System.Web.Security.MembershipCreateStatus exists in both 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\...' and '...\\my Project folder path'
I have tried everything...reinstalling NAnt, VS, verifying build file,etc.
I tried deleting that dll from my project folder. It then complains about {get; set} methods.
I even tried uninstalling .net 2.0 because that is what is causing all the problems, but that doesn't work since .net 2.0 folder cannot be deleted...
If it has to be deleted, i will have to mess with the registry, which i dont want to because I have specifics in there that I dont want to disturb.
Thanks in advance!!
Cheers!!
I could not have figured this out in a million years. One of my peers helped me with this one.
Solution:
Try to download NAnt (its a zipped folder)
Before you extract the folder you should right click on the zip file then select Properties and under the General tab, click the button labelled Unblock, then click OK on the Properties window.
Once you do that, extract the file to your desired location
4.Now change the path in your environmental variables
5.Open a new command Prompt and run NAnt
End of all problems...NAnt works awesome!!
Thanks!!
As above really, I have some integration tests that use files from a relative file path. To help picture it here is the file structure:
/Dependencies
/VideoTests/bin/release/video.dll
/SearchTests/bin/release/search.dll
/OtherProjects
The GUI is running the tests from the root, however when TeamCity runs the tests it is running the tests from each test dlls bin directory. Now I don't mind which one I can get to follow the other but I do need them to be the same otherwise my relative paths just won't work!
Any ideas?
P.S. Using TeamCity 5.0 and NUnit 2.5.
You probably don't want to rely on CurrentDirectory. I'd suggest reading the doc, but the main point you'll want to take away is that the CurrentDirectory is where the .exe was started from: it could be any path in the system. For example, let's assume your users add your .exe (or whatever .exe uses your DLLs) to their path. They could then navigate to c:\foo\bar and start the .exe from there, which would set the CurrentDirectory to "C:\foo\bar" and you may not be able to deal with that.
I think it would be preferable for you to rework whatever you're doing so you don't rely on CurrentDirectory. What problems are you encountering by relying on CurrentDirectory right now?
Have you made sure that both TeamCity and NUnit are using the same working directory when starting the application?
And if they aren't, you could adjust the current directory in the test code.