Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> "The path is not of a legal form." Error saving entity
 

Pages: 1
LLBLGen Pro Runtime Framework
"The path is not of a legal form." Error saving entity
Page:1/1 

  Print all messages in this thread  
Poster Message
JSobell
User



Location:

Joined on:
07-Jan-2006 06:44:46
Posted:
89 posts
# Posted on: 06-Sep-2016 01:12:39.  
I'm getting this error when saving an entity.
It appears to be related to fetching the runtime library, yet the project is referencing the latest nuget packages.
Any suggestions?

Code:

at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
at System.IO.Path.GetFullPathInternal(String path)
at System.IO.Path.GetFullPath(String path)
at System.Diagnostics.FileVersionInfo.GetFullPathWithAssert(String fileName)
at System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
at SD.LLBLGen.Pro.ORMSupportClasses.RuntimeLibraryVersion.get_Build()
at SD.LLBLGen.Pro.ORMSupportClasses.ORMException..ctor(String message, Exception innerException)
at SD.LLBLGen.Pro.ORMSupportClasses.ORMQueryExecutionException..ctor(String message, String queryExecuted, IList parameters, Exception innerException, Dictionary`2 exceptionInfo)
at SD.LLBLGen.Pro.ORMSupportClasses.ActionQuery.Execute()
at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterCore.ExecuteActionQuery(IActionQuery queryToExecute)
at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterCore.PersistQueue(List`1 queueToPersist, Boolean insertActions)
at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterCore.SaveEntity(IEntity2 entityToSave, Boolean refetchAfterSave, IPredicateExpression updateRestriction, Boolean recurse)
at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.<>n__14(IEntity2 entityToSave, Boolean refetchAfterSave, IPredicateExpression updateRestriction, Boolean recurse)
at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.<>c__DisplayClass15_0.<SaveEntity>b__0()
at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.ExecuteWithActiveRecoveryStrategy[T](Func`1 toExecute)
at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterBase.SaveEntity(IEntity2 entityToSave, Boolean refetchAfterSave, IPredicateExpression updateRestriction, Boolean recurse)
at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterCore.SaveEntity(IEntity2 entityToSave)
at ScriptBackend.Module.Data.DiskFileStorage.SaveScriptObject(IScriptEngine scriptService, Guid projectId, String scriptname, String script) in C:\QMTFS\Prototype\MicroServices\E3\Backend\ScriptBackend.Data\DiskFileStorage.cs:line 27
  Top
JSobell
User



Location:

Joined on:
07-Jan-2006 06:44:46
Posted:
89 posts
# Posted on: 06-Sep-2016 01:21:59.  
OK, resolved it.
We were using Fody Costura to package our DLLs as a single executable, and the LLBLGen couldn't find the assembly.
We've removed Costura for now, until we can review the process.


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37870 posts
# Posted on: 06-Sep-2016 07:11:30.  
Ah I see what's wrong: the save fails and you get an error, however to report that it needs to include the build/version number and it pulls that from the assembly info: the assembly file version contains the version number and it uses that as number to report in the exception. This goes wrong and you get that path error.

As you packed the assemblies together, the file version retrieval fails. This is kind of odd though, as it simply does:
Code:
var toReturn = FileVersionInfo.GetVersionInfo(typeof(RuntimeLibraryVersion).Assembly.Location).FileVersion;


I don't see how this wouldn't work, even if you ilmerge everything together.

Could you try check whether Assembly.Location is filled with something when you test it on a type in your code inside an assembly which you pack together with Costura?
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Alexander Muylaert
User



Location:
Geel, Belgium
Joined on:
05-Jul-2010 13:16:11
Posted:
223 posts
# Posted on: 11-Jul-2017 13:17:52.  
Otis wrote:
Ah I see what's wrong: the save fails and you get an error, however to report that it needs to include the build/version number and it pulls that from the assembly info: the assembly file version contains the version number and it uses that as number to report in the exception. This goes wrong and you get that path error.

As you packed the assemblies together, the file version retrieval fails. This is kind of odd though, as it simply does:
Code:
var toReturn = FileVersionInfo.GetVersionInfo(typeof(RuntimeLibraryVersion).Assembly.Location).FileVersion;


I don't see how this wouldn't work, even if you ilmerge everything together.

Could you try check whether Assembly.Location is filled with something when you test it on a type in your code inside an assembly which you pack together with Costura?


Hi

This is also a huge problem for us. We use the same techniques of embedding libraries in the exe and we also have this problem. And it sounds like a small thing, but in fact, it is huge, since we can't inform our customers anymore of constraints, uniqueness, errors, ...

Did somebody already came up with some workaround?


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37870 posts
# Posted on: 11-Jul-2017 13:38:44.  
In my post above I asked for whether the values contain some value but never received an answer back... could you debug the particular line of code (it's in ConstantsEnums.cs, line 1587) to see what's going on exactly? I think you can trigger this already by simply requesting RuntimeLibraryVersion.Build, so you don't need to first raise an exception to get this pop up.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Alexander Muylaert
User



Location:
Geel, Belgium
Joined on:
05-Jul-2010 13:16:11
Posted:
223 posts
# Posted on: 12-Jul-2017 09:30:55.  
Otis wrote:
In my post above I asked for whether the values contain some value but never received an answer back... could you debug the particular line of code (it's in ConstantsEnums.cs, line 1587) to see what's going on exactly? I think you can trigger this already by simply requesting RuntimeLibraryVersion.Build, so you don't need to first raise an exception to get this pop up.



Hi

I'll try to create a reproducable scenario for easy testing, below already the full error.



17:48:05.406 Database exception The path is not of a legal form.
17:48:05.415 ****************************** exception ******************************
17:48:05.415 ArgumentException
17:48:05.415 The path is not of a legal form.
17:48:05.415    at System.IO.Path.NewNormalizePath(String path, Int32 maxPathLength, Boolean expandShortPaths)
at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
at System.IO.Path.GetFullPathInternal(String path)
at System.IO.Path.GetFullPath(String path)
at System.Diagnostics.FileVersionInfo.GetFullPathWithAssert(String fileName)
at System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
at SD.LLBLGen.Pro.ORMSupportClasses.RuntimeLibraryVersion.get_Build()
at SD.LLBLGen.Pro.ORMSupportClasses.ORMException..ctor(String message, Exception innerException)
at SD.LLBLGen.Pro.ORMSupportClasses.ORMQueryExecutionException..ctor(String message, String queryExecuted, IList parameters, Exception innerException, Dictionary`2 exceptionInfo)
at SD.LLBLGen.Pro.ORMSupportClasses.ActionQuery.Execute()
at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterCore.ExecuteActionQuery(IActionQuery queryToExecute)
at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterCore.PersistQueue(List`1 queueToPersist, Boolean insertActions)
at SD.LLBLGen.Pro.ORMSupportClasses.UnitOfWork2.HandleInserts(DataAccessAdapterBase adapterToUseAsBase)
at SD.LLBLGen.Pro.ORMSupportClasses.UnitOfWork2.CommitImpl(IDataAccessAdapter adapterToUse, Boolean autoCommit)
at SD.LLBLGen.Pro.ORMSupportClasses.UnitOfWork2.<>c__DisplayClass47_0.<Commit>b__0()
at SD.LLBLGen.Pro.ORMSupportClasses.UnitOfWork2.Commit(IDataAccessAdapter adapterToUse, Boolean autoCommit)
at GOnline.Common.Dal.AbstractContext.<>c__DisplayClass50_0.<CommitUnitOfWork>b__1(IDatabaseConnection db)
at GOnline.Common.Dal.AbstractContext.DbDo(TransactionMode aTransactionMode, Action`1 aCodeToRun)
at GOnline.Common.Dal.AbstractContext.CommitUnitOfWork(UnitOfWork aUnitOfWork, Boolean aRaiseEvents)
at GOnline.Funboo.Dal.AbstractSalesOperations.Commit()


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37870 posts
# Posted on: 12-Jul-2017 10:09:44.  
Will wait for your path value....
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Alexander Muylaert
User



Location:
Geel, Belgium
Joined on:
05-Jul-2010 13:16:11
Posted:
223 posts
# Posted on: 12-Jul-2017 10:56:56.  
Otis wrote:
Will wait for your path value....


Hi

My Path is still loaded from inside memory, I'll get that in a second, would getting the code out of the attributes be an option for you?





        static bool s_Searched;
        static AssemblyFileVersionAttribute s_Attribute;

        static AssemblyFileVersionAttribute Attribute
        {
            get
            {
                if (!s_Searched)
                {
                    var all = typeof(RuntimeLibraryVersion).Assembly.GetCustomAttributes(true);
                    foreach (var x in all)
                    {
                        s_Attribute = x as AssemblyFileVersionAttribute;
                        if (s_Attribute != null)
                        {
                            s_Searched = true;
                            return s_Attribute;
                        }
                    }
                    s_Searched = true;
                }
                return s_Attribute;
            }
        }

        /// <summary>
        /// Contains the build number of this version, which is build up like semver: major.minor.patch.
        /// </summary>
        public static string Build
        {
            get
            {
                var toReturn = Attribute?.Version ?? FileVersionInfo.GetVersionInfo(typeof(RuntimeLibraryVersion).Assembly.Location).FileVersion;
#if NET45
                toReturn += "_WithAsync";
#endif
                return toReturn;
            }
        }


  Top
Alexander Muylaert
User



Location:
Geel, Belgium
Joined on:
05-Jul-2010 13:16:11
Posted:
223 posts
# Posted on: 12-Jul-2017 11:07:31.  
[quotenick="Alexander Muylaert"]
Otis wrote:
Will wait for your path value....




Just give me twenty minutes. It is building, merging, doing all its stuff and only then I can install this version and see what it is saying.

Yes, I know... since we have buildservers, we are almost back to Punched Cards speed in terms of debugging something on the "release" version
  Top
Alexander Muylaert
User



Location:
Geel, Belgium
Joined on:
05-Jul-2010 13:16:11
Posted:
223 posts
# Posted on: 12-Jul-2017 11:36:15.  
[quotenick="Alexander Muylaert"]
Alexander Muylaert wrote:
Otis wrote:
Will wait for your path value....




Just give me twenty minutes. It is building, merging, doing all its stuff and only then I can install this version and see what it is saying.

Yes, I know... since we have buildservers, we are almost back to Punched Cards speed in terms of debugging something on the "release" version



Hi

The location of the assembly is "", that is why the GetFileVersion fails.
I have checked the logic of going through the attribute on your dll and that does work fine though.

a quick solution would be hugely appreciated since thsi sounds silly, but we have apps crashing over things like "out of stock" and we don't know anything.

kind regards

Alexander


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37870 posts
# Posted on: 12-Jul-2017 14:07:05.  
Thanks for debugging. This is v5.2?
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Alexander Muylaert
User



Location:
Geel, Belgium
Joined on:
05-Jul-2010 13:16:11
Posted:
223 posts
# Posted on: 12-Jul-2017 14:33:12.  
Otis wrote:
Thanks for debugging. This is v5.2?


yup


  Top
Alexander Muylaert
User



Location:
Geel, Belgium
Joined on:
05-Jul-2010 13:16:11
Posted:
223 posts
# Posted on: 12-Jul-2017 14:33:24.  
Alexander Muylaert wrote:
Otis wrote:
Thanks for debugging. This is v5.2?


yup 5.2.1

  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37870 posts
# Posted on: 12-Jul-2017 15:45:17.  
thanks. will correct this now.

Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37870 posts
# Posted on: 12-Jul-2017 16:13:38.  
Please download the v5.2.2 hotfix build which contains updated code and which now retrieves the Fileversion attribute instead. If something goes wrong in that code it will fall back to the original code, but I think it's pretty straight forward. It caches the value like in your code too.

Code:

        #region Members
        private static bool _versionRetrieved = false;
        private static string _fileVersionFromAttribute = string.Empty;
        #endregion

        private static string RetrieveFileVersion()
        {
            try
            {
                if(!_versionRetrieved)
                {
                    var fileVersionAttribute = typeof(RuntimeLibraryVersion).Assembly.GetCustomAttributes(typeof(AssemblyFileVersionAttribute), true).FirstOrDefault() as AssemblyFileVersionAttribute;
                    if(fileVersionAttribute != null)
                    {
                        _fileVersionFromAttribute = fileVersionAttribute.Version;
                    }
                }
            }
            catch
            {
                // no recovery possible. swallow
            }
            finally
            {
                _versionRetrieved = true;
            }
            return _fileVersionFromAttribute;
        }


        /// <summary>
        /// Contains the build number of this version, which is build up like semver: major.minor.patch.
        /// </summary>
        public static string Build
        {
            get
            {
                var toReturn = RetrieveFileVersion();
                if(string.IsNullOrEmpty(toReturn))
                {
                    toReturn = FileVersionInfo.GetVersionInfo(typeof(RuntimeLibraryVersion).Assembly.Location).FileVersion;
                }
#if NET45
                toReturn += "_WithAsync";
#endif
                return toReturn;
            }
        }


Hopefully this corrects the issue for you!
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Alexander Muylaert
User



Location:
Geel, Belgium
Joined on:
05-Jul-2010 13:16:11
Posted:
223 posts
# Posted on: 12-Jul-2017 18:30:58.  
Hi Otis

Not to be bitchy, but any idea when it will be on nuget? I'm a very lazy man when it comes down to these things Regular Smiley

kind regards

Alexander


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37870 posts
# Posted on: 13-Jul-2017 09:25:14.  
It's on nuget, we always push the hotfixes to nuget as well, but they're pre-releases, so you have to check the 'pre-release' checkbox in the nuget interface to see them Regular Smiley
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.