Regen Data Model - Assembly files in wrong directory

FishyBC · October 23, 2019, 7:36pm

Whenever we run a Regenerate Data Model in any of our DEV or PROD environments, the Assembly files end up in C:\Users<USERNAME>\AppData\Local\Temp\Epicor\DataModelGenerator\Deployment\Server\Assemblies

They need to be in C:\inetpub\wwwroot\Epicor\Server\Assemblies

We move the 4 files manually everytime we do this but I’d like for it to put them in the correct place if possible. I don’t see any errors etc in the DataModelGenerator.log file

Is this a setting somewhere that I’m just not finding ? Is there a procedure I need to be following other than just running Regenerate Data Model during a maintenance window?

TobyLai · October 23, 2019, 9:14pm

Check the Deployment directory in the “Deployment Server” setting.

Check the Deployment Directory in the Application server setting. They should match up.

Normally after regen data model, you have to recycle the Application pool.

Rich · October 23, 2019, 11:27pm

When the Data Model is Regenerated, it is built and then compiled using a “Temp” location and then the Data Model is written to the Database. As an AppServer starts, the Data Model is pulled out of the Database and it is written into the Server\Assemblies directory.

You should not be manually moving any files into the Assemblies directory unless installing a hotfix.

Check out a previous post on this topic: Adding UDField - Procedure - #6 by Rich

hkeric.wci · October 24, 2019, 12:17pm

Ditto

FishyBC · October 24, 2019, 4:54pm

Thanks Rich. Very clear explanation.
We are now investigating which account is being used to write the files to the c:\inetpub\wwwroot\Epicor\Server\Assemblies directory.
The errors in the log are not overly descriptive but I’m thinking it might be a permissions issue writing to that directory. Is it the App Server account that does this or the Task Agent account ?

Rich · October 24, 2019, 8:00pm

AppServer / AppPool user identity.

Remember, you have to Stop the AppServer and then Restart - a Recycle may not allow us to replace the file even if the AppPool user has rights. By default, a Recycle starts a new instance even if the old instance is not finished. The AppPool “locks” the data model DLL while it is running so we cannot overwrite the data model when the new instance starts if the old instance is still running and has it locked.

FishyBC · October 24, 2019, 9:19pm

Richard,

I just did the following:

Stopped Application Pool from withine Epicor Admin Console
Regenerated Data Model
Once completed successfully, started the Application pool
Stopped and Started the Task Agent.

The 4 files
Erp.Data.910100.dll
Ice.Data.Model.dll
Erp.Data.910100.pdb
Ice.Data.Model.pdb

that were successfully generated from the Data model regen are showing in the temporary Assemblies location but it did not get updated in c:\inetpub\wwwroot\Epicor\Server\Assemblies.

Am I missing a step ?

Bart_Elia · October 24, 2019, 10:18pm

Turn on the hosting trace flag in appserver.config. That will show you the process of deploying the data model to the app server from the db and give more details

FishyBC · October 25, 2019, 4:39pm

Thank you Bart,
I have been running some traces but so far do not see anything related in them.
I cannot find an appserver.config file anywhere on the server or within the client files. I can find app.config in the Deployment directory but maybe I’m missing something here…
I am running the trace from Trace Options in the client with “Include Server Trace”.
Any further hints would be appreciated.
Pat

hkeric.wci · October 25, 2019, 5:34pm

Hmm interesting, it should be there wherever Epicor is installed (IIS Location):

FishyBC · October 25, 2019, 8:59pm

Losing my mind. Sorry. I just found it. Thanks

FishyBC · October 25, 2019, 10:49pm

Bart,
I see a thread you did about “How to write your own trace log” but it sounds from your post like you are saying that I can just turn on the Hosting Trace Flag from within the AppServer.Config file.
I’m looking in that file but do not see that TraceFlag. Do I need to create it ?

hkeric.wci · October 25, 2019, 11:04pm

It might just be the system/host one – just remove 

Bart_Elia · October 26, 2019, 5:04am

Correct on which one Haso. Apologies for using short hand for the name.

FishyBC · October 30, 2019, 8:26pm

Thank you both.
I ran this and after looking at the DataModelRegenerator.log file, I see no errors or nothing that points to why this might be happening. Here are the contents of the file:

Start time: 10/30/2019 1:12:57 PM
Database server: EpicorDEVServer
Database name: Epicor
Using Windows authentication: False
User ID: epicadmin
Schemas to include:
Tables to exclude: Ice.SysSequence, Ice.DBMigrationLog
Generator version: 3.1.600.0
Server version: 3.1.600.9
Folder C:\Users\USER\AppData\Local\Temp\Epicor\DataModelGenerator\Source is deleted successfully.
Extracting “Epicor.ServiceModel.dll” from “C:\Program Files (x86)\Common Files\Epicor Software\Database Manager Extensions\3.1.600\DataModelGenerator…\DbMigration.zip” to “C:\Users\USER\AppData\Local\Temp\Epicor\DataModelGenerator\Deployment\Server\Bin”.
Extracting “Epicor.System.dll” from “C:\Program Files (x86)\Common Files\Epicor Software\Database Manager Extensions\3.1.600\DataModelGenerator…\DbMigration.zip” to “C:\Users\USER\AppData\Local\Temp\Epicor\DataModelGenerator\Deployment\Server\Bin”.
Synchronizing schema changes.
Generating: C:\Users\USER\AppData\Local\Temp\Epicor\DataModelGenerator\Source\Server\Db\Ice.Data.Model\IceContext.edmx
Connecting to server/database: EpicorDEVServer/Epicor
connection opened and DB info retrieved. (4.30 s)
Generate EDMX
generate EDMX completed. (0.06 s)
Process Extended Tables
process of extended tables completed. (0.01 s)
Saving EDMX
save completed. (0.09 s)
Transform Model T4 template
transformation completed. (2.31 s)
Transform TempRowTypes T4 template
transformation of TempRowTypes completed. (0.48 s)
Build context project
build project completed. (7.47 s)
Total generation time (14.73 s)
Copying generated assembly to database: C:\Users\USER\AppData\Local\Temp\Epicor\DataModelGenerator\Source\Server\Db\Ice.Data.Model\obj\Release\Ice.Data.Model.dll
Generating: C:\Users\USER\AppData\Local\Temp\Epicor\DataModelGenerator\Source\Server\Db\Erp.Data.910100\ErpContext.edmx
Connecting to server/database: EpicorDEVServer/Epicor
connection opened and DB info retrieved. (19.55 s)
Generate EDMX
generate EDMX completed. (0.63 s)
Process Extended Tables
process of extended tables completed. (0.11 s)
Saving EDMX
save completed. (0.30 s)
Transform Model T4 template
transformation completed. (15.05 s)
Transform TempRowTypes T4 template
transformation of TempRowTypes completed. (4.29 s)
Build context project
build project completed. (74.79 s)
Total generation time (114.72 s)
Copying generated assembly to database: C:\Users\USER\AppData\Local\Temp\Epicor\DataModelGenerator\Source\Server\Db\Erp.Data.910100\obj\Release\Erp.Data.910100.dll
Checking for orphans
Data Models generated successfully: 10/30/2019 1:15:58 PM

Other suggestions ?

Rich · October 30, 2019, 11:17pm

Hey Pat -
This Topic has wandered a bit so let me provide a quick recap.

Your original complaint is that the Data Model Regeneration process does not write the Data Model DLLs to the Server\Assemblies directory. That is actually the correct behavior - the Data Models are written into the Database by the Regeneration Process. The DataModel DLLs that you have found in the AppData\Local\Temp directory structure is “lint” left over from the regeneration and compilation processing. You can see that processing in the Data Model Generator Log file you have posted.

As an AppServer Starts, the Data Model is pulled from the Database and is written to the Server\Assemblies folder. This is done so that in a configuration where multiple AppServers are used for load management, each one is correctly updated.

The Trace Flag that Bart asked you to add / enable in the AppServer.config will update the Server Log in the AppServer folder and it is that log you are interested in as it should give you information on the AppServer attempting to update the Data Model to the Server\Assemblies folder while it is starting.

DLLs referenced/used from the Server\Assemblies folder by the AppServer (W3WP) as it is running are “locked” and cannot be replaced by the AppServer as it starts if an instance of the AppServer is already running. As a result, you should follow this pattern when you are regenerating the Data Model:

Stop all Instances of the Task Agent - a running instance can keep an AppServer alive
Stop all Instances of AppServers servicing the Database
Regenerate the Data Model
Start all Instances of the AppServers for the Database
Start all Instances of the Task Agent

If the Data Models are not updated to the Server\Assemblies folder, review the AppServer Log and look for logged messages related to the AppServer start and the attempt to update the Server\Assemblies folder with the new Data Models.

If you are not able to discern anything useful from the Server Log, it is time to call Tech Support.

FishyBC · October 31, 2019, 7:40pm

Thank you Rich,
That is a very clear and helpful response !
Thank you so much …

My last question regarding this is, from looking at the log it seems to be a permission related issue of some sort. I have tried to identify all of the accounts. I’m guessing it is either the Task Agent that affects this or the account used in the Application Server Settings.

I have played with these but I’m still getting “The given path’s format is not supported” in the log.

-------- Inner exception --------->>>
The given path’s format is not supported. (NotSupportedException)
at System.Security.Permissions.FileIOPermission.EmulateFileIOPermissionChecks(String fullPath)
at System.IO.Directory.InternalCreateDirectoryHelper(String path, Boolean checkHost)
at Ice.Hosting.ServiceHostFactory.VerifyUpdatedDataModel(String dmPath, Dictionary`2 dmProps) in C:_Releases\ICE\3.1.600.9\Source\Framework\Epicor.System\Hosting\ServiceHostFactory.cs:line 221
]]>

<![CDATA[
Exception during DataModel download: System.NotSupportedException: The given path’s format is not supported.
at System.Security.Permissions.FileIOPermission.EmulateFileIOPermissionChecks(String fullPath)
at System.IO.Directory.InternalCreateDirectoryHelper(String path, Boolean checkHost)

Any thoughts or should I create a ticket ?
Thanks all for putting up with a Noobie !
Pat

Rich · October 31, 2019, 9:11pm

Pat -
As it is the AppServer that is moving the Data Model files from the DB to the File System, it is the AppPool Identity user that needs to have permission to read and write to the Assemblies directory as specified in Web.Config.

Have a look in the Web.Config file at the AssemblyFileSystem value. I believe that the code that writes the Data Model runs through all the Paths specified, and attempts to read the data models from each path and if they are not found, it will write the data models to the folder specified in the final Path of the AssemblyFileSystem value. I cannot recall what the 10.1.600 code did if it found the data models in anything other than the final folder of the Paths specified - throw error; delete data models; Overwrite with DB Version - but you need to ensure that the Path segments in the AssemblyFileSystem are valid and that the AppPool Identity user has at least read access to all and read/write access to the final Path folder.

FishyBC · November 13, 2019, 2:29pm

Update:
Just in case anyone else runs into this. It was a weird one. We have some customizations in our system and this requires a 2nd entry in the AssemblyFileSystem line in the web.config file.

I removed the one that was the customization entry and it worked as expected. I spoke with support and they said there cannot be an space between the 2 entries (after the semicolon) or it ignores the 2nd entry.
Once I removed the space, no more issue.

Thanks all for your help with this. I learned a bunch in the process.

hkeric.wci · November 18, 2019, 7:57am

Noted Awesome.

Thank you @Rich for providing some good intel and info related to Data Model!