Hi,

I upgraded model project to 4.3.0 (build 5536) version. Build of project was successfull. Domain.Build method throws exception:

Could not load file or assembly 'Xtensive.Storage.Providers.Sql, Version=1.0.0.0, Culture=neutral, PublicKeyToken=93a6c53d77a5296c' or one of its dependencies. The system cannot find the file specified.

I call this by this code:

var configuration = new DomainConfiguration(connectionString)
                                    {UpgradeMode = DomainUpgradeMode.PerformSafely};

            configuration.Types.Register(sourceType.Assembly, sourceType.Namespace);

            _mainDomain = Domain.Build(configuration);

References added to this project are:

PostSharp Xtensive.Core Xtensive.Core.Aspects Xtensive.Integrity Xtensive.Storage Xtensive.Storage.All Xtensive.Storage.Model Xtensive.Storage.Rse Xtensive.Sql.SqlServerCe

Used connection string (SqlServerCe): sqlserverce://user:password@localhost/C ... ain-nx.sdf

Which references are missing? Any suggestions to resolve this error?

Thanks

Tomas Bako


Updated at 20.07.2010 21:41:17

Upgrade tool didn't fix the problem. Fusion log shows follows:

=== Pre-bind state information === LOG: User = ** LOG: DisplayName = Xtensive.Storage.Providers.Sql, Version=1.0.0.0, Culture=neutral, PublicKeyToken=93a6c53d77a5296c (Fully-specified) LOG: Appbase = file:///X:/AlteaFinance/Source/Altea/bin/Debug/ LOG: Initial PrivatePath = NULL Calling assembly : Xtensive.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=93a6c53d77a5296c. === LOG: This bind starts in default load context. LOG: Using application configuration file: X:\AlteaFinance\Source\Altea\bin\Debug\Altea.vshost.exe.Config LOG: Using host configuration file: LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config. LOG: Post-policy reference: Xtensive.Storage.Providers.Sql, Version=1.0.0.0, Culture=neutral, PublicKeyToken=93a6c53d77a5296c LOG: The same bind was seen before, and was failed with hr = 0x80070002.


Updated at 22.07.2010 12:52:48

Okay,

I'll solve this problem by postbuild events, where xtensive assemblies will be copied to bin folder. This post thread is closed for me. :D

Why I don't want references to xtensive in main exe application? Because my application has 3 layers:

  1. Presentation and entry codes - main exe
  2. Biz layer = there are references to xtensive and bridge between presentation and data
  3. Data layer = there are pure xtensive models

If I will be forced to remove xtensive in future (for unknown reasons), I'll simply replace third layer for another one. First layer doesn't know, what happens in data layer and don't know who manage data.

I have one question: Why xtensive assemblies are not in GAC?

Tomas B.

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

asked Jul 19 '10 at 20:33

Editor's gravatar image

Editor
46154156157

Most likely you'll fix this by running DataObjects.Net Project Upgrade Tool (Tools menu in VS.NET) for the project you're executing (exe, web app, etc.) and checking "Copy indirect references" checkbox there.

(Jul 19 '10 at 20:33) Alex Yakunin Alex%20Yakunin's gravatar image

I recommend you to turn on Fusion Log to find out the cause. See e.g. this article for details.

(Jul 19 '10 at 20:33) Alex Yakunin Alex%20Yakunin's gravatar image

One Answer:

Alex (Xtensive) wrote:

Check your bin folder. Is Xtensive.Storage.Providers.Sql.dll there? Most likely, no, and this is the actual cause.

There are two ways to fix the issue: 1) Add necessary reference. Note that you should add few other references as well. Most of assemblies we ship must be referenced, because, although you don't need them, they'll be required by Xtensive.Storage.dll you're using - directly or indirectly. We could add these assemblies to GAC to avoid this, but in this case Bin folder of application won't contain its working deployable copy. 2) Alternatively, you can run Upgrade Tool and turn the options there as it's described on picture below. One of options there ensures all indirect references (except the ones in GAC) are copied to bin folder - that's exactly what you need in this case.


psulek wrote:

When i examine your solution than i found that your primary EXE (wpf) project has no references to any of xtensive..dll and also no Postsharp (dont know if is required here). But when i add these xtensive..dll (standard set) to your EXE project then everything works :-)

Alex: I run project upgrade tool with option "Add references to DataObjects.Net assemblies" but NO references was added. I must manually add these references to project.


psulek wrote:

Tomas ask me to remove direct references to xtensive (and Postsharp) from main WPF exe project, because he does not want to have direct references to DO4 from main app. Instead of this, have some business library which is references from main app. Described like: Altea (EXE, no direct references to xtensive or postsharp) -> Altea.Data (business lib, which has direct references to xtensive, also referenced model project 'Altea.Data.Model') -> Altea.Data.Model (DO4 model lib, which has direct references to xtensive and postsharp)

where project Altea.Data.Model has these imports:

<Import Project="$(DataObjectsDotNetPath)\Common\Defaults.ModelProject.targets" />
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="$(DataObjectsDotNetPath)\Common\DataObjects.Net.targets" />

and project Altea.Data has these imports:

<Import Project="$(DataObjectsDotNetPath)\Common\Defaults.DllProject.targets" />
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="$(DataObjectsDotNetPath)\Common\DataObjects.Net.targets" />

and main project Altea has these imports:

<Import Project="$(DataObjectsDotNetPath)\Common\Defaults.ExeProject.targets" />
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="$(DataObjectsDotNetPath)\Common\DataObjects.Net.targets" />

and when solution is built then Bin folder of project Altea.Data.Model contains file Xtensive.Storage.Providers.Sql.dll Bin folder of project Altea.Data also contains file Xtensive.Storage.Providers.Sql.dll

but Bin folder of project Altea does *NOT* contains file Xtensive.Storage.Providers.Sql.dll

i think that output bin folder of main project Altea should have all xtensive libs because proj file of EXE app has imported target Defaults.ExeProject.targets, no? Maybe some bug in target file Defaults.ExeProject.targets which does not copy all indirect references to bin output ?


Alex (Xtensive) wrote:

Using "Defaults.XxxProject.targets" is "old way" (but should work). I recommend you to run Upgrade Tool for the whole solution - it will fix this to "new way" (additional <property> definitions>).

> i think that output bin folder of main project Altea should have all xtensive libs because proj file of EXE app has imported target Defaults.ExeProject.targets, no?

Yes, it should, if DataObjects.Net.targets is also imported there.

So what't the content of this folder? Which .dlls are missing in comparison to other project's folders?


psulek wrote:

Using "Defaults.XxxProject.targets" is "old way" (but should work)...

"old way" - you must just joking Alex, right? In this topic (18 May, 2 months ago) you describe that with xxx.targets is NEW way and additional <property> is old way, and now you tell me reverse. What is right ?


Alex (Xtensive) wrote:

No, it's not a joke: on May 20 I implemented Upgrade Tool, and finally decided to use old way of describing options:

  • Since now Upgrade Tool handles this, it's better when such options are described as properties in .csproj

  • Dealing with a set of .target files might be more confusing for the people, especially because you should import two targets, and the first one must be properly chosen.

  • Upgrade Tool is capable to update all your project in solution to new way automatically. Just choose "Upgrade Solution" there, and it will do all the job by its own.

This approach is described in Manual shipped with v4.3 (in "Using DataObjects.Net in your projects and solutions" section).

But I fully agree that such a mess here is result of my wrong solution to use Defaults.ExeProject.targets files. On the other hand, I did all I could to fix it without significant inconvenience for you:

  • This approach still works (these .targets are still available in Common folder)

  • Upgrade Tool is capable of upgrading this automatically.


psulek wrote:

I made changes according to you (run project upgrade tool) on new sample project which i made for this situation (see attachment).

When you run MainApp (WPF application) then click on button which start to build DO4 Domain and fails that it cannot find Xtensive.Storage.Providers.Sql, Version=1.0.0.0, Culture=neutral, PublicKeyToken=93a6c53d77a5296c which really is not in Bin folder of main app. But when you open MainApp.csproj then it contains <copyindirectdependencies>true</copyindirectdependencies> but file Xtensive.Storage.Providers.Sql.dll (and others) are not copied to project output.


Alex (Xtensive) wrote:

I just checked this - true, indirect references aren't copied. But they get properly copied when you turn on "Add references to DataObjects.Net assemblies" option.

So I suspect current implementation of <copyindirectreferences> option inspects only assembly references, but not project references.

Not sure if we should fix this, since actually it's quite easy to workaround this by adding a single reference to Xtensive.Storage.All assembly:

<Reference Include="Xtensive.Storage.All, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
    </Reference>

Being @ your place, I'd simply add this reference to main application project ;) Or created your own assembly referencing this one, and added reference to that assembly.

Btw, I don't understand the reasons of not referencing our assemblies - I see no any negative consequences of this.


psulek wrote:

...I don't understand the reasons of not referencing our assemblies - I see no any negative consequences of this. I dont know exact reason, this problem is not mine, i just created sample solution to demonstrate the problem :-)

answered Jul 21 '10 at 02:33

Editor's gravatar image

Editor
46154156157

Putting them into GAC is bad as well. You can't deploy a solution by XCopy without copying them; deploying web application to remote web server isn't possible w/o copying them as well.

(Jul 21 '10 at 02:33) 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:

×574

Asked: Jul 19 '10 at 20:33

Seen: 2,682 times

Last updated: Jul 19 '10 at 20:33

powered by OSQA