outputDirectory lost on reload (override non functional)

Not sure if it’s just me. I’ll check on a separate PC tonight to verify and report back. But on latest version from nuget I’m no longer able to override the default directory.

Sequence is as follows:

1. In the .efmodel designer -> click on any entity
2. Choose a path from the dropdown in [outputDirectory] property
3. Save the .efmodel
4. Notice the file does not exist where specified
5. Check the still open .efmodel designer, and property is there as you had it.
6. Close the designer.
7. Edit the .efmodel in raw text editor, property “outputDirectory=” is present and valid.
8. reopen the designer.
9. Property has suddenly disappeared from table, and the .efmodel raw text reflects the lack of property.

It seems reloading the efmodel causes the outputDirectory property to be physically deleted from the table’s serialized properties in xml. And the save operation does not produce the file properly. Furthermore the xml file indicates a isOutputDirectoryTracking value of false, which based on source code grep scan for assignment, appears to indicate that the string value is NULL during serialization. Which may explain why it’s dropped when deserialized back to C#. Guessing here, but not sure why it would be null, and yet present in the xml serialized output?

Anyone else experiencing this as well by chance?

Edit: Can confirm:

• happens on multiple environments
• fresh install win 10 and vstudio 2019 enterprise & latest version(1.3.0.12)
• Recreated efmodel from scratch to confirm

Doesn’t appear to be asymptomatic, but not sure what’s wrong. Let me know any thoughts, and thank you!!! This product makes a major difference in the projects my team works on

[msawczyn]

Thank you both; I’ve got a bead on this one and it’ll be fixed in the upcoming release. I owe you a beer!

[msawczyn]

Glad to hear I can make a contribution to you and your team’s lives being a little easier. But regarding what you’re seeing … hard to say. What you describe (and you’ve dug deeper than I normally hope for in a problem report) shouldn’t be able to happen.

If you get a moment, you might try 2.0RC1 to see if it exhibits the same behavior. Note that, as of this release, it won’t work with VS2017 so, if that’s your environment, it won’t be something that will help. I have yet to update the docs, so the new features aren’t fully described, but they’re pretty self-explanatory and listed in the changelog in the main readme both here and on the Marketplace.