Entity Framework EF4.1 - la procédure stockée “n'a pas pu être trouvé dans le conteneur”

J'ai un SP dans ma base de données. Pour EF4.1, à l'aide de la API DbContext.

Après l'importation de la fonction à partir du modèle de données, les références à la procédure stockée fonctionne très bien dans mon environnement de développement. Mais lorsqu'ils sont publiés sur le serveur, il échoue avec un message du genre: Le FunctionImport 'SqlSearch" ne peut pas être trouvé dans le conteneur des "TallyJ2Entities'. Toutes les autres données d'accès fonctionne bien.

Il semble que dans la production, certains aspects de la EF4 de configuration sont oubliés.

Les bases de données sont identiques, et les deux serveurs SQL 2008 (local est Express SP1 10.50.2500, l'hôte est Express RTM 10.50.1600).

J'ai même fait l'EDMX éditeur directement à la base de données de production et de mise à jour. Le résultat a bien fonctionné dans le développement, mais ne parvient pas de la même manière sur le serveur.

D'autres questions similaires ici n'aident pas. Quelqu'un d'autre semble avoir un problème similaire entrez description du lien ici.

Des suggestions?

Mise à jour: j'ai trouvé que le problème disparaît lorsque le déploiement de l'armée dans le mode de Débogage!

À l'intérieur de mon DbContext classe dérivée, j'ai mis ce code:

((IObjectContextAdapter)this).ObjectContext.MetadataWorkspace
var findFunction = metadataWorkspace.GetItems(DataSpace.SSpace)
            .SelectMany(gi => gi.MetadataProperties)
            .Where(m=> Equals(m.Value, "SqlSearch"))
            .Select(m => "Found {0}".FilledWith(m.Value))
            .FirstOrDefault();

Quand je suis connecté le findFunction conséquent, il s'avère que le serveur (en mode Release) ne la trouve PAS, alors que dans le développement, il est trouvé.

Il semble y avoir de nombreuses questions concernant ceci: stackoverflow.com/a/3501174/2942 stackoverflow.com/questions/4892926/...
Merci. Mais aucun de ceux d'autres idées a fonctionné pour moi.

OriginalL'auteur Glen Little | 2011-12-11

  1. 19

    Si l'utilisation de EF 4.1 et au-dessus, le changement "ObjectParameter" à "SqlParameter" et "ExecuteFunction" à "ExecuteStoreQuery" dans votre Contexte.cs fichier.

    La "ExecuteStoreQuery" méthode s'attend aussi à vous d'ajouter les noms des paramètres, en face de la procédure stockée. Trouver un extrait de code ci-dessous:

    var param1Parameter = param1 != null ?
new SqlParameter("param1", param1) :
new SqlParameter("param1", typeof(string));

var param2Parameter = param2 != null ?
new SqlParameter("param2", param2) :
new SqlParameter("param2", typeof(int));

return ((IObjectContextAdapter)this).ObjectContext.ExecuteStoreQuery<sp_TestSproc_Result>("sp_TestSproc @param1, @param2", param1Parameter, param2Parameter);

    Si vous utilisez un modèle pour générer votre code, vous pouvez trouver le fragment de code ci-dessous utile aussi. I. e. J'ai modifié la norme "Fluent TT" générateur de fonction EF 4.3:

        void WriteFunctionImport(EdmFunction edmFunction, bool includeMergeOption)
{
var parameters = FunctionImportParameter.Create(edmFunction.Parameters, Code, EFTools);
var paramList = String.Join(", ", parameters.Select(p => p.FunctionParameterType + " " + p.FunctionParameterName).ToArray());
var returnType = edmFunction.ReturnParameter == null ? null : EFTools.GetElementType(edmFunction.ReturnParameter.TypeUsage);
var processedReturn = returnType == null ? "int" : "ObjectResult<" + MultiSchemaEscape(returnType) + ">";
if (includeMergeOption)
{
paramList = Code.StringAfter(paramList, ", ") + "MergeOption mergeOption";
}
#>
<#=AccessibilityAndVirtual(Accessibility.ForMethod(edmFunction))#> <#=processedReturn#> <#=Code.Escape(edmFunction)#>(<#=paramList#>)
{
<#+
if(returnType != null && (returnType.EdmType.BuiltInTypeKind == BuiltInTypeKind.EntityType ||
returnType.EdmType.BuiltInTypeKind == BuiltInTypeKind.ComplexType))
{
#>
((IObjectContextAdapter)this).ObjectContext.MetadataWorkspace.LoadFromAssembly(typeof(<#=MultiSchemaEscape(returnType)#>).Assembly);
<#+
}
foreach (var parameter in parameters.Where(p => p.NeedsLocalVariable))
{
var isNotNull = parameter.IsNullableOfT ? parameter.FunctionParameterName + ".HasValue" : parameter.FunctionParameterName + " != null";
var notNullInit = "new SqlParameter(\"" + parameter.EsqlParameterName + "\", " + parameter.FunctionParameterName + ")";
var nullInit = "new SqlParameter(\"" + parameter.EsqlParameterName + "\", typeof(" + parameter.RawClrTypeName + "))";
#>
var <#=parameter.LocalVariableName#> = <#=isNotNull#> ?
<#=notNullInit#> :
<#=nullInit#>;
<#+
}
var genericArg = returnType == null ? "" : "<" + MultiSchemaEscape(returnType) + ">";
var callParams = Code.StringBefore(", ", String.Join(", ", parameters.Select(p => p.ExecuteParameterName).ToArray()));
var spParams = Code.StringBefore("@", String.Join(", @", parameters.Select(p => p.EsqlParameterName).ToArray()));
if (includeMergeOption)
{
callParams = ", mergeOption" + callParams;
}
#>
return ((IObjectContextAdapter)this).ObjectContext.ExecuteStoreQuery<#=genericArg#>("<#=edmFunction.Name#> <#=spParams#>"
<#=callParams#>);
}
<#+
if(!includeMergeOption && returnType != null && returnType.EdmType.BuiltInTypeKind == BuiltInTypeKind.EntityType)
{
WriteFunctionImport(edmFunction, true);
}
}
    Merci... je vais essayer ça dans la prochaine semaine ou deux. Nous espérons être en mesure de sortir du mode Debug!
    Cela a fonctionné pour moi!
    Parfait, merci! Ne sais pas combien de temps ça m'aurait pris de la trouver par moi-même!
    Je suis en train de faire quelque chose de similaire, mais je ne le,t ont une sp j'ai une TABLE. Je serai de retour un message d'erreur indiquant: "la fonction n'est pas un sp, c'est une TABLE". Avez-vous une idée de comment cela pourrait être résolu?
    Merci, cela fonctionne pour moi.

    OriginalL'auteur Kwex

  2. 5

    Nous avons trouvé que c'était causé par le mauvais connectionString.

    EF besoins d'une chaîne de connexion qui ressemble à ceci:

    <connectionStrings>
<add name="MyModel_Entities" connectionString="metadata=res://*/Models.MyModel.csdl|res://*/Models.MyModel.ssdl|res://*/Models.MyModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=192.168.1.200;initial catalog=MyDb_Live;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework&quot;" providerName="System.Data.EntityClient" />
</connectionStrings>

    Où il est dit Monmodèle cela devrait correspondre avec le nom de votre .edmx fichier de modèle.

    Si vous avez copié un connectionString d'autre part, il peut ressembler à ceci:

    <add name="MyModel_Entities" connectionString="Data Source=.;Initial Catalog=MyDb_Live;Integrated Security=SSPI;MultipleActiveResultSets=true" providerName="System.Data.SqlClient" />

    De noter la différence dans la providerName à la fin de la connectionStrings.

    NB Nous sommes à l'aide de EF 6.1 mais je crois que cela s'applique aux versions antérieures.
    Si vous réparer votre chaîne de connexion que nous avons trouvé, vous pourrez continuer à utiliser le code généré par les modèles T4. Vous n'avez pas besoin de changer de ObjectParameter à SqlParameter et ExecuteFunction à ExecuteStoreQuery.

    Je suis d'accord... la chaîne de Connexion de formats sont essentiels pour l'EF. Merci pour mettre en évidence que.
    J'ai ajouté 2 EDMX dans mon projet et j'ai juste copier collé de la chaîne de connexion et cela a fini par être la solution pour moi. Parce que j'ai eu le tort "Monmodèle" il a regardé pour la procédure stockée dans un autre récipient. Merci

    OriginalL'auteur jksemple

  3. 0

    Je ne pense pas que la chaîne de connexion est la question.Dans mon cas, je ne suis pas capable de l'appel de procédure stockée, mais je suis capable d'écrire des données dans ma DB . cela signifie que notre connexion est bonne.

    OriginalL'auteur jai