I have a class library with all my nhibernate code (domain/mappings using fluent).
Now I am just doing some simple tests in a console application, and I am getting an error saying it can't find the configruation file in /bin/debug
I have the file in /consoleTests/hibernate.cfg.xml
Why would it be looking in the /bin/debug folder of the console application?
If you are calling the Configure() method without any parameters, then I believe that the hibernate.cfg.xml must be in the same directory as the application that uses it.
When you compile your project, it gets compiled to the bin/debug/ directory. When you run your project (by either clicking on it or debugging it in Visual Studio), the working directory is bin/debug/, so that is where the hibernate.cfg.xml file is expected to be.
You could:
use a post-build event within Visual Studio to copy the hibernate.cfg.xml file to the output directory
call Configure(path), where path is the path to your hibernate.cfg.xml in your /consoleTests/ directory.
Have a look at "A fluent interface to NHibernate - Part 4 - Configuration" for more detailed information on how to configure NHibernate.
You can set the xml property "Copy to Output Directory" to "Copy Always"
That's the current directory when running in Visual Studio. Is that what you're doing?
Related
I have to run two targets in parallel to profile iisexpress.exe using OpenCover.
The link below relates to the information about the issue I am having.
https://github.com/sawilde/opencover/issues/92#issuecomment-5143204
This suggested to me to use Msbuild.ExtensionPack from CodePlex.
I have downloaded the source code of MSBuild Extensions.
I compiled it. I copied the MSBuild.ExtensionPack.tasks tasks file in to folder BuildBinaries.
I added the below lines in my projects files.
I was trying to run the ExecMultipleTasks target. But getting the below error.
error MSB4036: The "MSBuild.ExtensionPack.Framework.Parallel" task was not found. Check the following:
1.) The name of the task in the project file is the same as the name of the task class.
2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface.
3.) The task is correctly declared with in the project file, or in the *.tasks files located in the "C:\Windows\Microsoft.NET\Framework\v4.0.30319" directory.
Could you please let me know how to fix this issue?
Thanks,
Venkat.
which version of visual studio your application is using ?, if its 32 bit of VS then install 32 bit Extension Pack (MSBuild.Extension.Pack.4.0.12.0.zip\4.0.12.0\x86) else go for 64 bit.
If you open up the file C:\Program Files (x86)\MSBuild\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks ill think you find that the path to the dll for the task MSBuild.ExtensionPack.Framework.Parallel is not correct.
<UsingTask AssemblyFile="$(ExtensionTasksPath)MSBuild.ExtensionPack.dll" TaskName="MSBuild.ExtensionPack.Framework.Parallel"/>
I imagine the variable $(ExtensionTasksPath) does not locate your build path for your version. Either copy the files into that path or change/hardcode the new path.
I have a web application that I am trying to deploy and have the web.config file parametrised.
I can build the package by running
msbuild myproj.csproj /T:package
now when it produces the package, i get a file in the directory.
Archive.SetParameters.Xml
This file has Parameters in it that if I change they would end up in the deployed package. My Question is, how can i define more parameters so that when I build the project it has my extra parameters in the file.
I belive i could do it using MSDeploy -declareParam But how would I do this from MSBuild? or the .csproj file.
My end goal is to have a parametrised Web.config file for deployment into multiple environments.
Ok so turns out this is fairly easy, after some significant googling eventually found this post
http://vishaljoshi.blogspot.com/2010/07/web-deploy-parameterization-in-action.html
VS 2010 makes your life easier by allowing you to simply drop the
Parameters file in the root of your web project and if a file with the
name Parameters.xml is found in the root of your project it passes it
to Web Deploy which then parameterizes your web…
I have a Visual Studio 2010 solution that is set to build in Debug x86. Visual Studio therefore sets the output path to \bin\x86\Debug, which seems logical enough.
The solution contains about 50 projects; the start-up project is a WCF project.
When I do a build, I would expect all output dlls to go to \bin\x86\Debug, as that is what is set in the project settings. But weirdly, I see dlls being created in bin\x86\Debug and in \bin. Why would Visual Studio put any dll in \bin if the output path is not set to that directory? It seems that all dlls go to \bin\x86\Debug, and all dlls except for the start-up project go into \bin. Any idea why it would do that? (We have other solutions that don't use WCF, and they don't have this problem.)
The other annoyance is if I run the service from Visual Studio and then try to access my service in a web browser, by going to http://localhost:1240/MyService.svc, it doesn't work, because the start-up project dll is missing from /bin. I therefore have to manually copy this one dll from \bin\x86\Debug to \bin, so that all dlls are found and the service runs normally. (We could of course add a custom post-build step that does the copy, but you'd think there'd be a better way!)
To those of you working on WCF projects, do you leave the output path at \bin\x86\Debug? (Perhaps there is a way to configure the service, eg in the web.config or .svc file, so that it knows the binaries are in \bin\x86\Debug instead of \bin?) Or do you change the output path to \bin so that you can run your service straight from Visual Studio?
If you open the property page of you WCF Hosting project and goto tab Build, under the Output section of this tag there is a textbox that contains the location of the output binaries.
For a WCF project the binaries should go to bin directory irrespective of the build type (suc as Debug, Release). Make sure this value has been configured correctly.
The value needs to be configured for each build type\configuration.
If you need, for whatever reason, different outputs from different build configurations in different folders you could specify them like you did first and use a post build event command line that copies from your specified output folder to bin.
Like:
- untested code -
COPY/Y "$(OutDir)\*.*" "$(SolutionDir)$(ProjectName)\bin\"
- untested code -
I have had my first successful build using CC.Net + MSBuild on legacy project. Only took 8 hours.
My newb question is: Where is the output?
My ArtifactDirectory is empty. Where did everything go?
Did you specify the ThoughtWorks.CruiseControl.MSBuild.dll logger in the msbuild-task? Did you have the xmllogger publisher?
EDIT:
What are you looking for : the results/logs that goes into the dashboard and mail or the website/dll/program you built?
Could you post your project configuration?
EDIT2:
The website/dll you built are located in the outDir you specified in your msbuild task. If you didn't override either the OutDir or the OutputPath property (in your msbuild task or msbuild build script) your website should be located in the WebProject\bin\Release (or Debug)_PublishedWebsites and your dlls should be located in every Project_dir\bin\Release (or Debug).
If you want a common output you need to specify it by overriding OutputPath or BaseOutputPath (see here http://msdn.microsoft.com/en-us/library/bb629394.aspx ).
If your source projects don't compile to custom folders, the code will be located wherever the source was pulled down to on the build box. As Benjamin stated, this will be the workingDirectory specified in the msbuild task.
If you didn't specify a working directory, I believe CruiseControl.net puts code in:
C:\Program Files\CruiseControl.NET\server\[Project Name]\WorkingDirectory
TFS 2008, VS 2008.
I have a tfsbuild.proj and tfsbuild.msp file in $/MyStuff/TeamBuildTypes/Dev folder.
I have a targets file at $/MyStuff/TeamBuildTypes/IncludeFiles/Common/test.xml.
test.xml contains an XML fragment that overrides the BeforeGet task.
I tried to get the file into my tfsbuild.proj file like this:
<Import Project="$/MyStuff/TeamBuildTypes/IncludeFiles/Common/test.xml" />
The build fails because it tries to get the file from a relative path that is way off.
I have shifted gears a little and am now trying an Exec task to get the file from TFS into the local filesystem.
<Exec WorkingDirectory="$(SolutionRoot)" Command=""$(TF)" get "$/MyStuff/TeamBuildTypes/IncludeFiles/Common/test.xml" /version:W$(WorkSpaceName) /overwrite /force /noprompt /recursive" IgnoreExitCode="true" />
I have no idea where the file is going. I don't get an error. I have access to the $(SolutionRoot) variable but the TeamBuildTypes folder is above that one in the filesystem. How can I get to this file and use it as an overrride to my task for the current build?
Help?
Thanks!
That's not a "remote" path. It's a path into TFS source control. It can only be understood by TFS.
MSBUILD is not part of TFS - it's part of the .NET SDK. It can only understand the kind of paths all programs can understand.
You'll have to fetch this file from source control onto the build machine, and reference it with a path to where you fetched it.