When I debug the following code, I receive the message "System.TypeLoadException was caught" when I perform the Delete().
Using db As New ScholarshipEntities
db.ApplicationHistories.Where(Function(h) h.HistoryTypeId = 0).Delete()
db.SaveChanges()
End Using
I am using EF 6.1 in Visual Studio 2013. I also have the EntityFramework.Extended library installed.
I have no trouble querying results. I thought the bug might occur when the Where method has no results, but that is not the case. I also have no problem adding new models (.edmx), which was a problem some people with this exception had.
I just recently upgraded to EF 6.1 and installed the Extended library. This is my first time using one of the extended methods. I've un-installed and re-installed the nuget packages with no success.
IntelliTrace shows the following exceptions from the Delete() call (in order):
'EntityFramework.Reflection.DynamicProxy' does not contain a definition for 'InternalQuery'
Cannot implicitly convert type 'EntityFramework.Reflection.DynamicProxy' to 'System.Data.Entity.Core.Objects.ObjectQuery<Scholarship.ApplicationHistory>'
Could not load type 'System.Data.Entity.Core.Mapping.EntityContainerMapping'
I've added an issue on the Extended library's github.
Update
I've reinstalled EF and the EF.Extended library with no luck. I am able to use RemoveRange in its place. I am able to create a new project, install the packages, add a model mapped to the same database, and successfully use Delete. Obviously, the problem is in my current solution.
In my solution, I have an ASP.NET project and a regular library project. In the ASP project, a page's code behind calls a method in the library RemoveHistory. The library contains classes for the business logic and data access. Both classes implement interfaces. The actual Delete occurs in the data access class. My model also resides in this library project.
I may be able to create a completely new project and bring everything over, but that will take quite some time. Even if I did, I want to understand why it doesn't work in the first place, so that I don't have to repeat this process.
If you want to delete certain rows do it like that:
Using db As New ScholarshipEntities
db.ApplicationHistories.RemoveRange(db.ApplicationHistories.Where(Function(h) h.HistoryTypeId = 0))
db.SaveChanges()
End Using
If you want to remove single entity do it like that:
Using db As New ScholarshipEntities
db.ApplicationHistories.Remove(db.ApplicationHistories.Single(Function(h) h.HistoryTypeId = 0))
db.SaveChanges()
End Using
I "solved" the issue some time ago. I'll eventually go back to try and reproduce the problem to confirm my suspicions.
There were multiple versions of Entity Framework installed in the solution. This didn't appear to affect basic EF functionality, though I'm sure it did in some subtle, potentially buggy fashion.
Every time the solution was opened, NuGet would state that it couldn't complete uninstallation. Uninstalling and restoring via NuGet was unsuccessful, and the packages had to be deleted manually. Once completely removed, I installed the packages again. This resolved the issue.
I wish I could give a more technical answer, though the basic reason was forgetting to look closer at the packages folder and configuration.
Related
In a simple windows form application on VS 2010 I have put a ovalShape using power packs.
The simple Form
Now automatically this action puts the reference of Microsoft.VisualBasic.PowerPacks.Vs in to project properties.
when deploying this in different PC obviously the (a)powerpacks needed to be installed if this application doesn't work, (b) or it can set to "copy local = true" in reference properties so that it should sit to next with the application.
assuming (b) is not an option, since it is a solitary executable, (a) is the only option. in this way if the target machine does not have powerpacks the requirement is to notify it to the user in the first place.
apparently the dll will be deployed in when using the "VisualBasicPowerPacksSetup"
C:\Windows\assembly\GAC_MSIL\Microsoft.VisualBasic.PowerPacks.Vs\10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualBasic.PowerPacks.Vs.dll
so the blind approach is just to check if the above file not exist then prompt user to install "VisualBasicPowerPacksSetup". but i feel its more accurate if the application able to actually check in registry level.
in registry "Microsoft.VisualBasic.PowerPacks" records in several location, thus makes a confusion.
how to identify the correct key and what should be correct way of checking this reference in vb ?
You could just try to create an object defined in the dependency and catch the resulting exception.
Handling this you could ask the user to install the package. This is probably not considered good practice but should get the job done.
Recently, my company started to focus Extension_v2 development for Dynamics NAV BC. We store our code in an internal Git-Server. So far, so good.
But startig a new project is still a very fiddly task. You have to create a repository, clone it, execute the AL Code-Task, move the files to the fitting location push the repository to the correct upstream etc. And all this does not include the first initial Steps (README, CHANGELOG and all other fundamental files...).
So I wanted to write a small PowerShell-Script, to do all these initial steps before being able to start working on the Project.
The Problem: I could not find a way to execute the "AL-GO!" task via script.
I have already searched the Internet and some forums for an answer... but it seems like microsoft did not consider the possibility to execute tasks from the AL-Language-Extension via script.
I also played around with the New-NAVAppManifest and the New-NAVAppManifestFile command for the old Extension_V1 development, but that did not do the trick.
I am looking for a fair and easy way to combine the creation of the app.json file and the launch.json file with other commands to easily initialize a new Project without haveing to write all commands manually. Maybe I did not recognize the easy solution. Or maybe this is just the way we have to do it in Extension_v2.
Anyway, thanks for all your help nevertheless.
Greetings.
Stay away from Ext V1. It's highly deprecated at this point.
First of all, why do you need to execute the "AL-Go!" via script? The "AL-Go!" command should already include all necessary steps to create an empty project including the launch.json and app.json. (minimal adjuments required dependent on your BC environment)
There is an extension/plugin for Git in Visual Studio Code which will handle all the repository stuff for you. You don't need to change file locations if everything is set up for Git. I rarely use it yet, but saw a demo for it on the Directions EMEA last year and I'm pretty sure it works at its current state (someone correct me if I'm wrong)
A way to implement the "AL-GO!" command for a script or for setting up additional steps in your project setup might be to write your own visual studio code extension/plugin which requires some additional know-how for that.
OR
You just change the settings/files of the default project, I bet there is at least a file for creating the initial AL project. Just change that to your requirements
Hi I'm getting an error in the VSO log and a build failure
d:\a\src-***--\r2rJSONcall.aspx.vb (31): 'rptJSONRoutesTable' is not
a member of 'r2rSearchResponse'.
And yet it is!
r2rJSONcall.aspx.vb
Public Class r2rJSONcall
...
Property r2rResponse As New r2rSearchResponse
...
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
'call the webservice..
...
Response.Write(r2rResponse.rptJSONRoutesTable("EUR"))
and in a classlibrary..
Public Class r2rSearchResponse
...
Function rptJSONRoutesTable(userCurrencyCode) As String
It, of course, runs locally no problem.
I've tried making a one byte change and recommitting, also the associated DLL was under source control, so I removed and add that. No Joy.
UPDATE - no, bad news the answer I posted below solved the problem temporarily. It has reared its ugly head once more and no matter what can't seem to get a build to work.
The following procedures have been tried so far to get a VSO online build to compile correctly:
1) I deleted my local folders and performed a full checkout from sourcecontrol - suggested by #MetaFight. That compiles fine locally, no files missing.
2) Excluded the /Bin and /Obj folders. So no dll's checked into source as suggested by #PhilipKendall
3) Run MSBuild locally. The solution compiles OK.
4) Renamed, and then moved function inside the classlib to try to trigger rebuild on Azure server. Still can't find the function.
5) Checked build order, Classlib is compiled first. "Clean" option selected on Build Profile.
6) Checked that references are correct. I can see the reference in the vbproj file. The reference are Project references, not file references.
7) Deleted Build Profile in Azure/VSO. Created new build defintition profile and new Web App in Azure - error reappears.
8) Tried this solution Library/Static Method not Updating in Azure No Merge error like point 3) on that page.
Any TFS/VSO experts out there can help?
We working in a small team and new member with no VSO experience has come onboard. He's working on the frontside AJAX, JSON, CSS, HTML5 - no need to use the classlibs or anything else - just submitting his code via TFS.
I suspected he might be an issue, so fixed up remote access and went in. He'd not updated Windows 7 since new - around 4 years. "Never had a BSOD" was the response. He was trying to install IIS which the machine wasn't very happy about it, so could not test locally, I don't know what the webserver in Visual Studio was doing - his system was not in English. Anyway I right-clicked where I would have done on the English version and did a recursive pull - then clicked on what looked like the Pending Changes and did a checkin.
Success - solution built OK.
I told my programmer to delete Visual Studio and never do a checkout again on that PC - and am providing him a remote desktop with fully patched machine and software.
You can do one of the following methods:
1) Did you check "Enable Nuget Package Restore" for your project?
You can use the following documentation for doing that:
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
Or:
2) Read the source below, it may help you if first method is not applicable for you or don't help:
http://blog.codingoutloud.com/2013/08/31/are-you-missing-an-assembly-reference-why-yes-i-am-so-kind-of-you-to-ask/
I hope both offered method support your question.
Apologies for not coming back sooner.
As discussed the problem came back even though it did manage to build after checkin from the rogue programmer, it subsequently went back to not building.
In the end we renamed the classlib (by right clicking and rename). Then checked the references to that classlib from all the other projects that require it. There was one subproject that on "add.. reference..." did not have the checkbox on, but in Properties of the project and references did. So this must have re-established the line in the vbproj file correctly.
Congo we build!
I have a DLL that is a logging component that we use in many different projects. This logging component is designed to be entirely self-contained, and thus it must have its database connection string internal to it. In this project, it is completely unacceptable to require that its connection string be copied to the app.config of any project that uses it.
This has been working great for years, but now we have found that mixing its older ADO tech with new apps that use EF results in horrible performance when the logging is being done. For example, adding a single log entry when the application starts results in a > 30 second delay before the app opens.
So to combat this, I have re-written this component to use EF.
The problem is under the current EF (version 4.4 since we are targeting .Net Framework 4.0) does not offer a constructor to DBContext that allows you to specify the entire connection string. The code attempts to change the Database.Connection.ConnectionString, but the DBContext object insists on looking in the App.Config for the connection string even though we are giving it a new one.
I must get around this behavior.
I am using RavenDb across multiple projects and solutions to access three different databases that are all part of the same product. For instance, I have multiple MVC projects that fetch user info and some data out of the 'web' centric database and the 'backend' database, using '-' for the id override (but I need this only for a subset of classes in the 'web' db). And then I have another 'backend' database that is used by services (as well as the MVC projects). And finally a third temp/scratch database I use by another set of services to build the backend db. And of course, all of these are being accessed from different class libraries and even console test, seed, and integration test apps.
Managing all of these is becoming quite a nuisance. Every time I create a new console app or class library that access the db, I have to setup config and raven packages for each project, make sure indexes are built, etc.... Not to mention running update on all nuget updates, or in my case, installing a new unstable version of the server/client binaries.
Is there an easier way to manage this?
I tried to abstract the DocumentStore creation and initialization, as well as index creation into it own project and reference that. But the other projects then had to manually add newtonsoft.json (and nlog) from the package directory.
As well, I am getting the following when I try and abstract the DocumentStore into a class with a static property:
StackTrace of un-disposed document store recorded. Please make sure to dispose any document store in the tests in order to avoid race conditions in tests.
Anyone have any thoughts on handling these issues?
Thanks
I don't think that the manual addition of the references is a big issue, but you can add the actual nuget references as well.
Note that the DocumentStore not disposed error is something that only happened in the unstable (debug builds), and won't happen on release builds.