Hello,

I am trying to build my solution that uses DO4, on a build server where DO4 is not installed. More generally, my purpose is to make it possible for developpers to simply get the whole project from the repository and then be able to build the solution straight away (in particular without having to install DO4 as a prerequisite, or without defining environment variables)

Therefore I changed the following in my .csproj files : <import project="$(DataObjectsDotNetPath)\\Common\\DataObjects.Net.targets"/> to <import project="..\\Some\\Path\\Common\\DataObjects.Net.targets"/> (and of course I copied the hierarchy in C:\Program Files\DataObjects.Net to "..\Some\Path\" )

However, I get the following error at the build :

Cannot locate DataObjects.Net. You must install it to use 'DataObjects.Net.targets' file.   DonatelloLite

Is it possible to build a project without installing DO ?

Best regards, Auguste


Updated at 16.11.2009 14:22:16

Hello Alex,

Yes: you should add a single line to the beginning of your .csproj: <dataobjectsdotnetpath>$(MSBuildProjectDirectory)...\DataObjects.Net</dataobjectsdotnetpath> Everything else is unnecessary.

I also had to redefine the variables depending on $DataObjectsDotNetPath. (Possibly because of the 'Condition=' clauses in the DataObjects.Net.targets file, but I am no MSbuild expert.) Specifically, I had to add the following to my .csproj (otherwise my VisualStudio2008 would not open the project):

<DataObjectsDotNetPath>.\..\ExternalLibs\DataObjects.Net</DataObjectsDotNetPath>
    <DataObjectsDotNetLibDir>$(DataObjectsDotNetDir)Lib\</DataObjectsDotNetLibDir>
    <DataObjectsDotNetBinDir>$(DataObjectsDotNetDir)Bin\Latest\</DataObjectsDotNetBinDir>
    <DataObjectsDotNetCommonDir>$(DataObjectsDotNetDir)Common\</DataObjectsDotNetCommonDir>
    <XtensiveMSBuildTasksPath>$(DataObjectsDotNetCommonDir)Xtensive.MSBuildTasks</XtensiveMSBuildTasksPath>
    <PostSharpPath>$(DataObjectsDotNetLibDir)PostSharp</PostSharpPath>
    <PostSharpPluginsPath>$(DataObjectsDotNetBinDir).</PostSharpPluginsPath>

My project now builds correctly, but I get the following runtime error at the domain build (recreate mode) :

L'exception System.InvalidOperationException n'a pas été gérée
  Message="Could not load types from the assembly 'Xtensive.Storage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=93a6c53d77a5296c'."
  Source="Xtensive.Core"
  StackTrace:
       at Xtensive.Core.Reflection.AssemblyHelper.FindTypes(Assembly assembly, Type baseType, TypeFilter filter) in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Core\Xtensive.Core\Reflection\AssemblyHelper.cs:line 60
       at Xtensive.Core.Collections.TypeRegistrationHandlerBase.Process(TypeRegistry registry, TypeRegistration registration) in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Core\Xtensive.Core\Collections\TypeRegistrationHandlerBase.cs:line 31
       at Xtensive.Core.Collections.TypeRegistry.ProcessPendingActions() in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Core\Xtensive.Core\Collections\TypeRegistry.cs:line 124
       at Xtensive.Core.Collections.TypeRegistry.GetEnumerator() in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Core\Xtensive.Core\Collections\TypeRegistry.cs:line 158
       at System.Linq.Enumerable.Count[TSource](IEnumerable`1 source)
       at Xtensive.Storage.ModuleProvider..ctor(DomainConfiguration configuration) in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Storage\Xtensive.Storage\ModuleProvider.cs:line 113
       at Xtensive.Storage.Upgrade.UpgradingDomainBuilder.Build(DomainConfiguration configuration) in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Storage\Xtensive.Storage\Upgrade\UpgradingDomainBuilder.cs:line 49
       at Xtensive.Storage.Domain.Build(DomainConfiguration configuration) in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Storage\Xtensive.Storage\Domain.cs:line 286
       at Test.Program.Main(String[] args) in D:\Perforce\DonatelloLite\DonatelloLite\Program.cs:line 38
       at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: System.Reflection.ReflectionTypeLoadException
       Message="Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information."
       Source="mscorlib"
       StackTrace:
            at System.Reflection.Module._GetTypesInternal(StackCrawlMark& stackMark)
            at System.Reflection.Assembly.GetTypes()
            at Xtensive.Core.Reflection.AssemblyHelper.FindTypes(Assembly assembly, Type baseType, TypeFilter filter) in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Core\Xtensive.Core\Reflection\AssemblyHelper.cs:line 57
       InnerException:

What did I get wrong ?

Best regards,

Auguste


Updated at 16.11.2009 17:44:35

this must not be necessary: declarations in .targets files are processed sequentially, so if you define DataObjectsDotNetPath before importing DataObjects.Net.targets, everything must work properly. Note that you must specify an absolute path there - that's why I suggested using syntax like this: <dataobjectsdotnetpath>$(MSBuildProjectDirectory)..\ExternalLibs\DataObjects.Net</dataobjectsdotnetpath>

The problem was indeed solved by defining DataObjectsDotNetPath with the $(MSBuildProjectDirectory) variable. (it is indeed unnecessary to define other variables that DataObjectsDotNetPath . (BTW, Xtensive.Storage.dll assembly was in the output folder)

Thx for your help !

Best regards,

Auguste


Updated at 25.11.2009 14:02:26

I had to face the problem posted here once more, but this time I found the origin of this problem : An (unhandled) InvalidOperationException is thrown during the domain build when the file Microsoft.Practices.ServiceLocation.dll provided by DO4 ($(DataObjectsDotNetPath)Lib\CommonServiceLocator) is not copied in the output folder.

The stack strace of the exception is :

L'exception System.InvalidOperationException n'a pas été gérée
  Message="Could not load types from the assembly 'Xtensive.Storage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=93a6c53d77a5296c'."
  Source="Xtensive.Core"
  StackTrace:
       at Xtensive.Core.Reflection.AssemblyHelper.FindTypes(Assembly assembly, Type baseType, TypeFilter filter) in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Core\Xtensive.Core\Reflection\AssemblyHelper.cs:line 60
       at Xtensive.Core.Collections.TypeRegistrationHandlerBase.Process(TypeRegistry registry, TypeRegistration registration) in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Core\Xtensive.Core\Collections\TypeRegistrationHandlerBase.cs:line 31
       at Xtensive.Core.Collections.TypeRegistry.ProcessPendingActions() in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Core\Xtensive.Core\Collections\TypeRegistry.cs:line 124
       at Xtensive.Core.Collections.TypeRegistry.GetEnumerator() in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Core\Xtensive.Core\Collections\TypeRegistry.cs:line 158
       at System.Linq.Enumerable.Count[TSource](IEnumerable`1 source)
       at Xtensive.Storage.ModuleProvider..ctor(DomainConfiguration configuration) in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Storage\Xtensive.Storage\ModuleProvider.cs:line 113
       at Xtensive.Storage.Upgrade.UpgradingDomainBuilder.Build(DomainConfiguration configuration) in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Storage\Xtensive.Storage\Upgrade\UpgradingDomainBuilder.cs:line 49
       at Xtensive.Storage.Domain.Build(DomainConfiguration configuration) in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Storage\Xtensive.Storage\Domain.cs:line 286
       at Test.Program.Main(String[] args) in D:\Perforce\DonatelloLite\DonatelloLite\Program.cs:line 38
       at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: System.Reflection.ReflectionTypeLoadException
       Message="Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information."
       Source="mscorlib"
       StackTrace:
            at System.Reflection.Module._GetTypesInternal(StackCrawlMark& stackMark)
            at System.Reflection.Assembly.GetTypes()
            at Xtensive.Core.Reflection.AssemblyHelper.FindTypes(Assembly assembly, Type baseType, TypeFilter filter) in c:\TeamCity\buildAgent\work\6a5d81309423096e\Xtensive.Core\Xtensive.Core\Reflection\AssemblyHelper.cs:line 57
       InnerException:

The message in the exception is not clear. However, since I could not find Microsoft.Practices.ServiceLocation in the GAC, I guess that the cause of the problem is that the file is missing, and not that another (inappropriate) version of the dll is used instead of the one provided by DO. If that is the case, then a FileNotFoundException would be more appropriate, and more helpful for troubleshooting.

I solved this problem by replacing <import project="$(DataObjectsDotNetPath)\\Common\\CopyIndirectDependencies.targets"/> by the following : <import project="$(DataObjectsDotNetPath)\\Common\\DataObjects.Net.targets"/>

The main project in my solution now gets its indirect references with <import project="$(DataObjectsDotNetPath)\\Common\\DataObjects.Net.targets"/> in its.csproj. Most of the indirect references get copied, but I still have to reference Xtensive.Storage.All. Since this main project references a library project that uses DO4 (and therefore references Xtensive.Storage.All), I would expect the 'CopyIndirectDependencies' to also copy Xtensive.Storage.All in the output folder of the main project.

Why are there some indirect references that are not copied by CopyIndirectDependencies ?

Best regards,

Auguste

(PS : I can provide some sample code if you want)

This thread was imported from our support forum. The original discussion may contain more detailed answer.

asked Nov 12 '09 at 11:14

Auguste's gravatar image

Auguste
25888

Yes: you should add a single line to the beginning of your .csproj:

<DataObjectsDotNetPath>$(MSBuildProjectDirectory)\...\DataObjects.Net</DataObjectsDotNetPath>

Everything else is unnecessary.

(Nov 12 '09 at 11:14) Alex Yakunin Alex%20Yakunin's gravatar image

One Answer:

Basically, this is the same as overriding environment variable in .csproj.

We use a bit different approach in ORMBattle.NET: we modified our DataObjects.Net.targets there (in fact, relative path in encoded there, see line #9). But generally this approach is not recommended (likely, we'll revert to the option described here).


> I also had to redefine the variables depending on $DataObjectsDotNetPath.

There must be other constants dependent on it in .target files, so I suspect just redefining other constants in case of wrong behavior won't help.

But anyway, this must not be necessary: declarations in .targets files are processed sequentially, so if you define DataObjectsDotNetPath before importing DataObjects.Net.targets, everything must work properly.

Note that you must specify an absolute path there - that's why I suggested using syntax like this:

<DataObjectsDotNetPath>$(MSBuildProjectDirectory)\..\ExternalLibs\DataObjects.Net</DataObjectsDotNetPath>

The error you get indicates there is no Xtensive.Storage.dll assembly in the output folder, or one of its dependencies absents. Likely, that's because there are issues with above line.


> The problem was indeed solved by defining...

Perfect!

> Xtensive.Storage.dll assembly was in the output folder

Well... Since now it does not matter, I'll avoid inventing other possible reasons of that exception ;)

answered Nov 12 '09 at 12:45

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412

Btw, initially we thought about the way you tried to use. But we couldn't get it working, because MSBuild does not provide any way to get path of the current .targets file.

(Nov 12 '09 at 12:45) Alex Yakunin Alex%20Yakunin's gravatar image

Thank you for notifying us - I'll check this today. Right now I can't explain why this could happen - it seems it is really properly referenced.

(Nov 12 '09 at 12:45) Alex Yakunin Alex%20Yakunin's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

Subscription:

Once you sign in you will be able to subscribe for any updates here

Tags:

×573

Asked: Nov 12 '09 at 11:14

Seen: 2,736 times

Last updated: Nov 12 '09 at 11:14

powered by OSQA