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 :-)