Hi,

After having upgraded from 4.0.5 to 4.1.0, I experienced the following issues : [1] - Build error: PostSharp: The plug-in "Xtensive.Core.Weaver" required by the assembly "Xtensive.Storage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=93a6c53d77a5296c" was not found.

-> This problem was fixed by adding the following in the PropertyGroup section of the .csproj : <usepostsharp>true</usepostsharp> <dontimportpostsharp>true</dontimportpostsharp>

[2] - Runtime error: Could not load file or assembly 'Xtensive.Sql.sqlserver, Version=1.0.0.0, [...]' or one of its dependencies. The system cannot find the file specified."

-> This problem was fixed by adding a reference to 'Xtensive.Sql.sqlserver' to my project.

[3] - Runtime error: I get a DomainBuilderException during the Domain build : DomainBuilderException : Persistent attribute isn't applied. Add the following line to AssemblyInfo.cs for "Test" assembly: [assembly: Persistent(AttributeTargetAssemblies = "Test")]. However, the AssemblyInfo.cs file already has the line with Persistent attribute.

Please find here after the complete stack traces (pressing 3 times F5 after the first exception occurs) : Exception #1

System.NullReferenceException s'est produite
  Message="Object reference not set to an instance of an object."
  Source="Microsoft.Practices.ServiceLocation"
  StackTrace:
       at Microsoft.Practices.ServiceLocation.ServiceLocator.get_Current() in c:\Home\Chris\Projects\CommonServiceLocator\main\Microsoft.Practices.ServiceLocation\ServiceLocator.cs:line 17
  InnerException:

Exception #2 :

L'exception System.NullReferenceException n'a pas été gérée par le code utilisateur
  Message="Object reference not set to an instance of an object."
  Source="Microsoft.Practices.ServiceLocation"
  StackTrace:
       at Microsoft.Practices.ServiceLocation.ServiceLocator.get_Current() in c:\Home\Chris\Projects\CommonServiceLocator\main\Microsoft.Practices.ServiceLocation\ServiceLocator.cs:line 17
       at Xtensive.Core.IoC.ServiceLocator.get_GlobalLocator()
  InnerException:

Exception #3:

L'exception Xtensive.Storage.DomainBuilderException s'est produite
  Message="Persistent attribute isn't applied. Add the following line to AssemblyInfo.cs for \"Test\" assembly: [assembly: Persistent(AttributeTargetAssemblies = \"Test\")]."
  Source="Xtensive.Storage"
  StackTrace:
       at Xtensive.Storage.Building.Validator.EnsureUnderlyingTypeIsAspected(TypeDef type)
       at Xtensive.Storage.Building.ModelInspector.Inspect(TypeDef typeDef)
       at Xtensive.Storage.Building.ModelInspector.InspectTypes()
       at Xtensive.Storage.Building.ModelInspector.Run()
       at Xtensive.Storage.Building.Builders.ModelBuilder.Run()
       at Xtensive.Storage.Building.Builders.DomainBuilder.BuildModel()
       at Xtensive.Storage.Building.Builders.DomainBuilder.BuildDomain(DomainConfiguration configuration, DomainBuilderConfiguration builderConfiguration)
       at Xtensive.Storage.Upgrade.UpgradingDomainBuilder.BuildStageDomain(UpgradeStage stage)
       at Xtensive.Storage.Upgrade.UpgradingDomainBuilder.Build(DomainConfiguration configuration)
       at Xtensive.Storage.Domain.Build(DomainConfiguration configuration)
       at Test.Program.Main(String[] args) in D:\Projets\Test\Program.cs:line 38
  InnerException:

Questions: 1- Problems [1] and [2] seem to indicate that the build process that I use is not correct anymore for DO4. Since my projects were created with DO 4.0.5, I could not use the project templates provided in the samples without rewriting all my projects. Could you provide some information about best practices or recommendations on how to build an application that uses DO4 ?

2- How can I fix problem [3] ?

Best regards,

Auguste


Updated at 10.11.2009 11:16:31

Hello,

I created a new project from scratch using the template provided in Visual Studio, and added my source code files. Everything works perfectly in that case.

Then I compared the two .csproj files with a merge tool and edited .csproj of the migrated project : now both .csproj files are identical . However, I am still not able to have a migrated version that works : a NullReferenceException occurs at runtime for the migrated project.

I already : - removed bin and obj folders before build - checked that the .sln files are identical (except of coarse for the path to the csproj)

What else can I check ? I can send you the source code of both projects for further investigation.

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

asked Nov 09 '09 at 16:37

Auguste's gravatar image

Auguste
25888


One Answer:

Yes, your analysis is fully correct. Likely, you didn't add this line to .csproj:

<Import Project="$(DataObjectsDotNetPath)\Common\DataObjects.Net.targets" />

See http://blog.alexyakunin.com/2009/10/add ... w-way.html

Another good way to check if everything is correct is to create similar project based on our on template, compare your own with it by some 2-way comparison/merge tool (e.g. Beyond Compare) and migrate all the missing parts from:

  • All <propertygroup> sections
  • <itemgroup> <reference> sections
  • <import> sections.

I apologize for inconvenience. Most likely, this is the last serious change to build process we made: current solution allows us to control everything there.


We resolved the issue:

It seems you turned on "Break on exceptions" option in VS.NET. So the exception you see exception is really thrown, but it will be caught by the calling code later. There are just few places in DO4 leading to the similar (throw-catch silently) scenarios, and we're going to eliminate them further. In this case the exception is thrown by third-party component we use, and there is no simple way to prevent it in this case, although the situation it is thrown in is normal for us. It's like checking the presence of some key if DIctionary doesn't have TryGetValue and Contains methods. So you can: - either press F5 and continue the execution (but you'll face few other exceptions further - you must press F5 again in these cases) - disable "Break on exceptions" (~ Debug -> Exceptions in VS.NET) - disable it for particular exception types (nearly the same place). Thank you for this answer, you are indeed correct : pressing F5 shows that the exception is handled and the program continues normally. By creating the project from stratch, the exception handling was set differently in VS (only stop on unhandled exceptions). That is indeed why the behavior of the two projects seemed to be different ! ... We know such exceptions is a bad practice (they make debugging more complex) that must be avoided by all means, and we really do this. But, as I said, there are still some places where they're thrown and caught (btw, currently we ensure this happens just once per a particular case, so normally they occur just on startup) - mainly, because we didn't invent a fast enough way to check something without an exception. E.g. reflection could be used to look inside some field of third-party type to prevent an exception (as it could be done with ServiceLocator), but this is slow. So we must think how to deal with such cases.

answered Nov 09 '09 at 17:51

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412

Yes, please.

Send the source code to support@x-tensive.com.

We'll examine it immediately.

(Nov 09 '09 at 17:51) Dmitri Maximov Dmitri%20Maximov'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

powered by OSQA