Using 2.50.50, we get the following error.
A file gallery.info is created with the following contents:
// Custom tool 'DevartEfGenerator' failed.
// - The process cannot access the file 'C:\Documents and Settings\russ\My Documents\Visual Studio 2008\Projects\Gallery\Gallery\GalleryManager\GalleryModel.edps' because it is being used by another process.
//
Background to the above error
In our database, we added an additional column. To ensure that the entity framework, reflected this addition, we added a new column in the storage schema, added a new property in the conceptual schema, mapped one to the other and saved.
We called the Entity Developer from within Visual Studio 2008.
Visual Studio also claims the .edps file to be locked.
The Database is MSSQL 2005
We do not get a lock under any other circumstances.
Cannot access the .edps file as it is used by another proces
-
PangoChris
- Posts: 12
- Joined: Mon 14 Sep 2009 20:11
Just wanted to chime in that we're getting hit by this too in Entity Developer 2.50.51 using dotConnect for Oracle for LINQ to SQL models, and have a different workaround in place.
The Run Custom Tool workaround didn't work for us, instead we have to run Entity Developer outside of Visual Studio by double clicking the lqml file from Windows Explorer. After we make changes to our model in Entity Developer we do the two step process of selecting Save to save the model and then selecting Generate to re-generate the code in the designer file. (I'm under the impression that when working correctly, Entity Developer automatically does the re-generation step when Saving if Entity Developer was launched from Visual Studio.)
Thought I'd share that in case it helps anyone else until there's a fix.
The Run Custom Tool workaround didn't work for us, instead we have to run Entity Developer outside of Visual Studio by double clicking the lqml file from Windows Explorer. After we make changes to our model in Entity Developer we do the two step process of selecting Save to save the model and then selecting Generate to re-generate the code in the designer file. (I'm under the impression that when working correctly, Entity Developer automatically does the re-generation step when Saving if Entity Developer was launched from Visual Studio.)
Thought I'd share that in case it helps anyone else until there's a fix.
The fix in 2.50.51 looked promising, but actually has resulted in the problem occuring some of the time, instead of all the time. (It's like playing Russian Roulette)
We are also shutting down Visual Studio and running Entity Developer on it's own, when we want to make changes at the moment.
Looking forward to a full fix in the new version.
We are also shutting down Visual Studio and running Entity Developer on it's own, when we want to make changes at the moment.
Looking forward to a full fix in the new version.
-
PangoChris
- Posts: 12
- Joined: Mon 14 Sep 2009 20:11
We're getting much closer.
The new version fixes the issue for us. When launching Entity Developer from Visual Studio and saving changes, everything works as expected. Thank you.
But...
We use Visual Source Safe (sigh... I know, I know) and now we get the edps message when Undoing a Check-Out on the LQML file. The check-out is indeed undone, but our data context designer file gets nuked locally and replaced with the edps error message, even though Entity Developer isn't running at the time.
Here's how we reproduce this:
1. From Visual Studio 2008 using a project which is checked in to Source Safe, right click a LQML file (DataContext.lqml in our case) and select "Check Out for Edit". This will check out the lqml file and its associated files (.Designer.vb, .edps, .lqml.view, and .vb) and make them writable. (Source Safe sets the read only file attribute on files that aren't checked out)
2. Double click the LQML file to launch Entity Developer. Make a change such as adding a new table to the data context from the database. Save, then close Entity Developer.
Everything's good so far. The correct changes have been made to the lqml and associated files. In fact, if I check these changes into Source safe by right clicking on the lqml file and selecting "Check In", everything will work. The files will be checked in and the local copies will have their read only attribute set. But if we don't like the changes we've made and instead...
3. Right click the LQML file and select "Undo Checkout..." and when prompted about losing our changes select "Yes to All", the checkout will be undone but now our DataContext.Designer.vb file's contents have been trashed and replaced with:
'Custom tool 'DevartLinqToSqlGenerator' failed.
' - Access to the path 'C:\CBP_Apps\Data\DataContext.edps' is denied.
'
Raising the question as to why DevartLinqToSqlGenerator has been run on an Undo Checkout operation.
Fortunately, this only affects the local copy of the designer file. The Undo Checkout command successfully reaches Source Safe, and all the files except the .Designer.vb file end up with their readonly attributes set. Visual Studio doesn't know that anything went wrong, as it displays the designer file in Solution Explorer with the source safe lock icon, indicating that it thinks it's readonly (which is incorrect) and not checked out (which is correct).
The workaround is to right click the LQML file again, and this time select "Get" which will try to get the latest version of the LQML file and its associated files, and in doing so detect that the designer file is writable (which it shouldn't be) and then prompt to restore the file from Source Safe, which is what we want.
The new version fixes the issue for us. When launching Entity Developer from Visual Studio and saving changes, everything works as expected. Thank you.
But...
We use Visual Source Safe (sigh... I know, I know) and now we get the edps message when Undoing a Check-Out on the LQML file. The check-out is indeed undone, but our data context designer file gets nuked locally and replaced with the edps error message, even though Entity Developer isn't running at the time.
Here's how we reproduce this:
1. From Visual Studio 2008 using a project which is checked in to Source Safe, right click a LQML file (DataContext.lqml in our case) and select "Check Out for Edit". This will check out the lqml file and its associated files (.Designer.vb, .edps, .lqml.view, and .vb) and make them writable. (Source Safe sets the read only file attribute on files that aren't checked out)
2. Double click the LQML file to launch Entity Developer. Make a change such as adding a new table to the data context from the database. Save, then close Entity Developer.
Everything's good so far. The correct changes have been made to the lqml and associated files. In fact, if I check these changes into Source safe by right clicking on the lqml file and selecting "Check In", everything will work. The files will be checked in and the local copies will have their read only attribute set. But if we don't like the changes we've made and instead...
3. Right click the LQML file and select "Undo Checkout..." and when prompted about losing our changes select "Yes to All", the checkout will be undone but now our DataContext.Designer.vb file's contents have been trashed and replaced with:
'Custom tool 'DevartLinqToSqlGenerator' failed.
' - Access to the path 'C:\CBP_Apps\Data\DataContext.edps' is denied.
'
Raising the question as to why DevartLinqToSqlGenerator has been run on an Undo Checkout operation.
Fortunately, this only affects the local copy of the designer file. The Undo Checkout command successfully reaches Source Safe, and all the files except the .Designer.vb file end up with their readonly attributes set. Visual Studio doesn't know that anything went wrong, as it displays the designer file in Solution Explorer with the source safe lock icon, indicating that it thinks it's readonly (which is incorrect) and not checked out (which is correct).
The workaround is to right click the LQML file again, and this time select "Get" which will try to get the latest version of the LQML file and its associated files, and in doing so detect that the designer file is writable (which it shouldn't be) and then prompt to restore the file from Source Safe, which is what we want.
Same problem
Hi devart team,
this problem is forced since last developer version (2.50.55)!
If you open two solutions referencing the same entityModel dll project the designer file is sometimes deleted. Also if you change the edml file for version management check out or after save of this file from external editors.
The external generator should only run during the before build event and never ever if the edml file was changed or touched!
The second time is the SaveAll in the EntityDeveloper .
And the generation should also work if app.config and project.config is ReadOnly! The generator tries to write this files and fails, if this files can not be written.
A warning is enought, if it not succeeds to write this files?
Tnx
Roman
this problem is forced since last developer version (2.50.55)!
If you open two solutions referencing the same entityModel dll project the designer file is sometimes deleted. Also if you change the edml file for version management check out or after save of this file from external editors.
The external generator should only run during the before build event and never ever if the edml file was changed or touched!
The second time is the SaveAll in the EntityDeveloper .
And the generation should also work if app.config and project.config is ReadOnly! The generator tries to write this files and fails, if this files can not be written.
A warning is enought, if it not succeeds to write this files?
Tnx
Roman
Build-events
Hi Andrey,
Look at the external tool for microsoft DataSet definitions MSDataSetGenerator, this external tool does not run and try to build the Designer.cs-File if the XSD-definition file is checked out or changed by an external tool! (But ok, it has no build action installed)
It makes no sence that all open studios starting generation of the designer.cs file if the edml file has changed or was checked out from version control system! This seems to be the reason, why the designer.cs file was removed sometimes.
It would be nice, if the DevartEntityDeploy would run automatically during the pre build phase, but only if the edml file has some changes. And if so, it has to ask for overwriting the readOnly designer.cs
Tnx,
Roman
Look at the external tool for microsoft DataSet definitions MSDataSetGenerator, this external tool does not run and try to build the Designer.cs-File if the XSD-definition file is checked out or changed by an external tool! (But ok, it has no build action installed)
It makes no sence that all open studios starting generation of the designer.cs file if the edml file has changed or was checked out from version control system! This seems to be the reason, why the designer.cs file was removed sometimes.
It would be nice, if the DevartEntityDeploy would run automatically during the pre build phase, but only if the edml file has some changes. And if so, it has to ask for overwriting the readOnly designer.cs
Tnx,
Roman
ReadOnly retry....
Hi Devart team,
it was fixed, but in the current version the error comes back...
Version of EntityDeveloper is 3.50.128
The newest release build of the integrated VS2010 designer does not overwrite the edps file if it is ReadOnly!
(SaveAll on open integrated designer).
Shows a MessageBox that the edps is ReadOnly..
If you call SaveAll from a different source, than the correct question is asking you if you want to overwrite the ReadOnly edps file!
Roman
it was fixed, but in the current version the error comes back...
Version of EntityDeveloper is 3.50.128
The newest release build of the integrated VS2010 designer does not overwrite the edps file if it is ReadOnly!
(SaveAll on open integrated designer).
Shows a MessageBox that the edps is ReadOnly..
If you call SaveAll from a different source, than the correct question is asking you if you want to overwrite the ReadOnly edps file!
Roman