So I pulled the source from https://svn.castleproject.org/svn/castle/DynamicProxy/trunk/
Open it up in vs.net 2008
problems:
vs.net can't open the assembly.cs
assembly signing failed
What am I doing, rather NOT doing?
Update
So I downloaded nant, setup the .bat file in my PATH so it works in cmd prompt.
I ran:
nant default.build
Getting this error:
build failed, \buildscripts\common-project.xml (48,3)
invalid element . Unknown task or datatype.
How exactly do I build the dynamicProxy project now?
update
This is what I did, see screenshot:
oh and my nant is:
#echo off
"E:\dev\tools\nant-bin\nant-0.86-nightly-2009-05-05\bin\Nant.exe" %*
http://img697.imageshack.us/img697/5623/castlebuildscreenshot.png http://img697.imageshack.us/img697/5623/castlebuildscreenshot.png
You can read the FM (how to build.txt). :)
You need to run the build script first using NAnt (http://nant.sf.net). This will generate the assembly.cs file. Take a look at the .build files in the tree to see what they are doing.
As for the assembly signing failing, check the project settings to get rid of references to CastleKey.snk. It should sign it using DynProxy.snk (in theory).
UPDATE:
The issue with NUnit is now fixed. Do a clean check out. I really have no idea why you're getting that error. Which version of NAnt are you using? Make sure you have the latest (earlier do not have support for .NET 3.5)
You should be able to just pull the source from the trunk, and build with nant (I just did that and it worked). Ok, I lied, looks like the reference to NUnit is wrong, so the unit test project will not build correctly:
BUILD FAILED - 0 non-fatal error(s), 1 warning(s)
D:\OLD\DynamicProxy\buildscripts\common-project.xml(295,5):
'nunit-console.exe' failed to start.
The system cannot find the file specified
Total time: 1.2 seconds.
BUILD FAILED
Nested build failed. Refer to build
log for exact reason.
Total time: 3.4 seconds.
However the important stuff (assemblyinfo generation) will succeed and you should be able to just open Castle.DynamicProxy2-vs2008.sln, fix the reference to the NUnit assembly hit F5 and build the code with no issues.
I just did it on a clean check out, and it worked.
Generally if you're planning to do modifications in DP codebase, it is advised to go to the Castle user group first, and discuss it there.
Related
I posted a similar question here.
Unfortunately, this issue is coming up again after having upgraded our build machines to run on Visual Studio Online 2015's Build and Release Manager.
This is the error that I get from a solution that generates Fakes assemblies used in unit testing:
D:\builds\TFS2015agent_2_work\1\.sonarqube\bin\targets\SonarQube.Integration.targets(240,5):
error MSB3491: Could not write lines to file "D:\builds\TFS2015agent_2_work\1\.sonarqube\out\\f_AnyCPU_Release_9840\FilesToAnalyze.txt".
The process cannot access the file 'D:\builds\TFS2015agent_2_work\1\.sonarqube\out\f_AnyCPU_Release_9840\FilesToAnalyze.txt' because it is being used by another process. [D:\builds\TFS2015agent_2_work\1\s\FakesFilePath\f.csproj] [D:\builds\TFS2015agent_2_work\1\s\FakesFileProj]
2016-09-13T20:01:37.6477261Z GENERATEFAKES : error : project compilation failed with exit code 1 [D:\builds\TFS2015agent_2_work\1\s\FakesFilePath\]
Does anyone have an idea of why this is happening? What process is causing the error? Could it possibly be related to the fakes compiling while SonarQube tries to access it?
I've been working on this particular issue for a couple weeks now, and I'm exceedingly frustrated. As such, I'll give all the information I can and hope for the best.
My team is working on building a new application. Here's the alphabet soup:
.Net 4.5.1
nHibernate 4.0.0.4000 with FluentNHibernate 2.0.3.0
Oracle 11g (Oracle.DataAccess 2.112.1.0, which has Copy Local set to true)
Visual Studio 2013 is the IDE
Windows 7 Professional
I am compiling the application as a 32-bit app, and I have confirmed that I have the 32bit version of Oracle installed.
We've written some tests for the NHibernate mappings, which we run through MSTest. When we run these through Visual Studio's test explorer, they all run properly and pass. The application itself also properly compiles and deploys as it should. We've verified the tests are running properly by checking the database between steps, so we're fairly sure that the tests themselves aren't the problem.
When we run MSTest through the command line though, we receive the following error:
Initialization method MyTests.Setup threw exception. NHibernate.HibernateException: NHibernate.HibernateException: Could not create the driver from NHibernate.Driver.OracleDataClientDriver. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentException: Unable to find the requested .Net Framework Data Provider. It may not be installed..
I've tried reinstalling Oracle to no effect. I've tried checking the machine.config file for errors (as suggested in other posts here on SO) and found none.
Our Fluent configuration is as follows:
OracleDataClientConfiguration.Oracle10
.ConnectionString(connectionString)
.Driver("NHibernate.Driver.OracleDataClientDriver")
.ShowSql()
.FormatSql();
The code I'm running on the command line is the following:
(cd to the directory where the test .dll is)
>"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\MSTest.exe" /testcontainer:MyTests.dll /test:UnitTests
I feel like I'm missing something here. Any ideas?
Update: Solution Found
So here's a weird one. I followed Fran's solution below and installed the Oracle.ManagedDataAccess package and changed the NHibernate driver in our configuration above to NHibernate.Driver.OracleManagedDataClientDriver. As per our quick comment-discussion, this lead to a new error:
Initialization method MyTests.Setup threw exception. NHibernate.HibernateException: NHibernate.HibernateException: Could not create the driver from NHibernate.Driver.OracleManagedDataClientDriver. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Configuration.ConfigurationErrorsException: Failed to find or load the registered .Net Framework Data Provider
Fran then lead me to another SO question which encouraged me to check the Oracle configuration piece by piece. What better way to do this than create a test?
var x = new OracleConnection(connectionString);
x.Open();
Assert.IsTrue(x.State == System.Data.ConnectionState.Open);
x.Close();
Assert.IsFalse(x.State == System.Data.ConnectionState.Open);
In my quick attempt to run this test, I ran the whole collection of UnitTests with the script I'd mentioned above. Low and behold, every test passes!
Doing my due diligence, try the following
I comment out that test, clean, rebuild, and run the script again. Failures.
I return to the old Oracle driver and add that new test in. Clean, Rebuild, Run. Failures.
Add back the new Oracle driver, make sure the new test is still in. Run tests OTHER than the new test. Passes.
For some reason, the combination of the new driver and explicitly referencing it in a test seems to have resolved the issue. I'm open for any theories as to why, but I bet that qualifies as a new question.
I would stop using the bit specific version of the oracle drivers and move to the managed driver (https://www.nuget.org/packages/Oracle.ManagedDataAccess/). It is bit agnostic, and doesn't require you to install the Oracle client at all.
I actually found the solution to the problem, and it all has to do with how the Oracle.DataAccess.dll file gets loaded at runtime (Disclosure: I work with wadeb on the same project).
It seems that Oracle.DataAccess.dll was being searched for in every location on the server except the build output folder in the Jenkins workspace, and as such was pulling the DLL file from the GAC.
One of the file paths used to find the DLL file is the folder in which the "current executable" is located. In our case, the "current executable" was mstest.exe. Copying the Oracle.DataAccess.dll file to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE did the trick.
Did it work. Yes.
Was it a hack? Absolutely -- but now it works without having to upgrade to the managed Oracle drivers.
Our servers weren't using an Oracle client that worked with the managed driver, and it wasn't acceptable to have a broken continuous integration build until servers get upgraded.
I have got just the same error and I switched my tests to x64 and it works like a charm now:
I've got CI builds set up for my project that use MS .Net (with AppVeyor) and Mono (with Travis CI).
The current build has a problem in that it tries to run an executable which is missing. This fails the AppVeyor build:
Starting Target: Run Unit Tests (==> BuildUnitTests, BuildIntegrationTests, BuildSampleApplication)
Running build failed.
Error:
System.Exception: Start of process HttpClient.UnitTests/bin/Release\HttpClient.UnitTests.exe failed. The system cannot find the file specified
at Fake.ProcessHelper.directExec#218.Invoke(String message) in C:\code\fake\src\app\FakeLib\ProcessHelper.fs:line 218
at Fake.ProcessHelper.directExec(FSharpFunc`2 configProcessStartInfoF) in C:\code\fake\src\app\FakeLib\ProcessHelper.fs:line 213
at FSI_0001.Build.clo#68-3.Invoke(Unit _arg3) in C:\projects\http-fs\build.fsx:line 71
at Fake.TargetHelper.runSingleTarget(TargetTemplate`1 target) in C:\code\fake\src\app\FakeLib\TargetHelper.fs:line 411
But the Travis build just carries on regardless, apparently not getting an exception:
Starting Target: Run Unit Tests (==> BuildUnitTests, BuildIntegrationTests, BuildSampleApplication)
Cannot open assembly 'HttpClient.UnitTests/bin/Release/HttpClient.UnitTests.exe': No such file or directory.
Finished Target: Run Unit Tests
(see https://travis-ci.org/relentless/Http.fs/builds/57475713)
This is the code that fails (or not):
ProcessHelper.directExec (fun procInfo ->
procInfo.FileName <- Path.Combine(unitTestsDir, "bin/Release", "HttpClient.UnitTests.exe")
) |> ignore
Any idea why this difference exists, and more importantly how to make it the same on Mono? (In this situation, I'd really like the build to fail). Of course, in this case I could check for the file's existence, but ideally I want the build to fail on any problem.
Edit
The problem, specifically, is that the build does not fail under Mono when I think it should. It seems that the exception which is raised on MS .NET due to the missing exe is either not raised or swallowed on Mono, resulting in a build which passes when it should (IMO) fail.
Looks to me like the file ends up in bin/Debug, not bin/Release.
On line 1244 in the build output you have:
Copying file from '/home/travis/build/relentless/Http.fs/HttpClient.UnitTests/obj/Release/HttpClient.UnitTests.exe' to '/home/travis/build/relentless/Http.fs/HttpClient.UnitTests/bin/Debug/HttpClient.UnitTests.exe'
Observations:
On our Jenkins build server, we were seeing lots of msbuild.exe processes (~100) hanging around after job completion with around 20mb memory usage and 0% CPU activity.
Builds using different versions of stylecop were intermittently failing:
workspace\packages\StyleCop.MSBuild.4.7.41.0\tools\StyleCop.targets(109,7):
error MSB4131: The "ViolationCount" parameter is not supported by the "StyleCopTask" task.
Verify the parameter exists on the task, and it is a gettable public instance property.
Nuget.exe was intermittently exiting with the following access violation error (0x0000005):
.\workspace\.nuget\nuget install .\workspace\packages.config -o .\workspace\packages"
exited with code -1073741819.
MsBuild was launched in the following way via a Jenkins Matrix job, with 'BuildInParallel' enabled:
`msbuild /t:%Targets% /m
/p:Client=%Client%;LOCAL_BUILD=%LOCAL_BUILD%;BUILD_NUMBER=%BUILD_NUMBER%;
JOB_NAME=%JOB_NAME%;Env=%Env%;Configuration=%Configuration%;Platform=%Platform%;
Clean=%Clean%; %~dp0\_Jenkins\Build.proj`
After a lot of digging around and trying various things to no effect, I eventually ended up creating a new minimal solution which reproduced the issue with very little else going on. The issue turned out to be caused by msbuild's multi-core parallelisation - the 'm' parameter.
The 'm' parameter tells msbuild to spawn "nodes", these will remain alive after the build has ended, and are then re-used by new builds!
The StyleCop 'ViolationCount' error was caused by a given build re-using an old version of the stylecop.dll from another build's workspace, where ViolationCount was not supported. This was odd, because the CI workspace only contained the new version. It seems that once the StyleCop.dll was loaded into a given MsBuild node, it would remain loaded for the next build. I can only assume this is because StyleCop loads some sort of singleton into the nodes processs? This also explains the file-locking between builds.
The nuget access violation crash has now gone (with no other changes), so is evidently related to the above node re-use issue.
As the 'm' parameter defaults to the number of cores - we were seeing 24 msbuild instances created on our build server for a given job.
The following posts were helpful:
msbuild.exe staying open, locking files
http://www.hanselman.com/blog/FasterBuildsWithMSBuildUsingParallelBuildsAndMulticoreCPUs.aspx
http://stylecop.codeplex.com/discussions/394606
https://github.com/Glimpse/Glimpse/issues/115
http://msdn.microsoft.com/en-us/library/vstudio/ms164311.aspx
The fix:
Add the line set MSBUILDDISABLENODEREUSE=1 to the batch file which launches msbuild
Launch msbuild with /m:4 /nr:false
The 'nr' paremeter tells msbuild to not use "Node Reuse" - so msbuild instances are closed after the build is completed and no longer clash with each other - resulting in the above errors.
The 'm' parameter is set to 4 to stop too many nodes spawning per-job
I had the same issue. One old reference I found was in csproj files
<PropertyGroup>
<StyleCopMSBuildTargetsFile>..\packages\StyleCop.MSBuild.4.7.48.0\tools\StyleCop.targets</StyleCopMSBuildTargetsFile>
Also, I deleted the entire "Packages" folder that's located in the same folder as sln file after I closed the visual studio. It triggered VS to rebuild the folder and let go of the cache of the old version of stylecop
I've had the same issue for a while, builds were taking over 6 minutes to finish after some digging I found our it's node reuse fault so adding /m:4 /nr:false fixing my issue immediately
I have a rather large solution, which contains two documentation projects based on Sandcastle + Sandcastle Help File Builder (SHFB). These projects both build correctly from the command line (msbuild project.shfb) and also using the beta version of SHFB Visual Studio 2010 integration.
When I run the build in TeamCity though, I get a mysterious build failure within the documentation build. The SHFB log says this:
[Sandcastle Help File Builder, version 1.9.3.0]
Cached Resolve Reference Links 2 Component. Copyright © 2006-2011, Eric Woodruff, All Rights Reserved
http://SHFB.CodePlex.com
Info: CachedResolveReferenceLinksComponent: Loaded 61 cached MSDN URL entries
Info: SaveComponent: Instantiating component.
Info: BuildAssembler: Building topic N:MyProject
Info: BuildAssembler: Building topic T:MyProject.ActionNotImplementedException
Info: BuildAssembler: Building topic AllMembers.T:MyProject.ActionNotImplementedException
Info: BuildAssembler: Building topic Methods.T:MyProject.ActionNotImplementedException
Info: BuildAssembler: Building topic Properties.T:MyProject.ActionNotImplementedException
Info: BuildAssembler: Building topic Overload:MyProject.ActionNotImplementedException.#ctor
Info: BuildAssembler: Building topic M:MyProject.ActionNotImplementedException.#ctor
Info: BuildAssembler: Building topic M:MyProject.ActionNotImplementedException.#ctor(System.String)
BUILDASSEMBLER : error : CachedCopyFromIndexComponent: An access error occured while attempting to load the file 'C:\Program Files (x86)\Sandcastle\Data\Reflection\mscorlib.xml'. The error message is: Could not find file 'C:\Program Files (x86)\Sandcastle\Data\Reflection\mscorlib.xml'. [C:\BuildAgent\work\37c2302839b8996f\Help\Output\Developer\Working\BuildReferenceTopics.proj]
Last step completed in 00:02:31.3827
</buildStep>
<buildStep step="Failed">
SHFB: Error BE0043: Unexpected error detected in last build step. See output above for details.
</buildStep>
</shfbBuild>
Sure enough, the file that Sandcastle is looking for (mscorlib.xml) is not there. But the build works outside of TeamCity, so I would conclude that Sandcastle is only looking for that file when TeamCity is onvolved. So, why does this only cause a failure in TeamCity and not from the command line within msbuild? I'd appreciate any troubleshooting hints because I'm out of inspiration.
Clarification (thanks #Sayed): The TeamCity build agent is the same computer where I can successfulyl run the command line build, so it's the same computer for everything mentioned above. The TeamCity Server is a different computer but that takes no part in the build.
I hit the same problem today, and I eventually managed to solve it: you just need to delete the cache files in the %USERPROFILE%\AppData\Local\EWSoftware\Sandcastle Help File Builder\Cache folder.
(note: since your problem is related to TeamCity, perhaps the files are in the TeamCity data folder instead)
In my case, I think it's because the cache files had been generated with an older version of SHFB, and were not compatible with the new version.