I have updated my project in EF 4.0 to EF 4.3.1.
However, when I create a new Context object, an exception is thrown:
Culture is not supported.
Parameter name: name
2.3.2 is an invalid culture identifier.
The complete Stack Trace:
at System.Globalization.CultureInfo..ctor(String name, Boolean useUserOverride)
at System.Globalization.CultureInfo..ctor(String name)
at System.Reflection.AssemblyName.nInit(RuntimeAssembly& assembly, Boolean forIntrospection, Boolean raiseResolveEvent)
at System.Reflection.AssemblyName..ctor(String assemblyName)
at System.Data.Metadata.Edm.MetadataAssemblyHelper.ComputeShouldFilterAssembly(Assembly assembly)
at System.Data.Common.Utils.Memoizer`2.<>c__DisplayClass2.<Evaluate>b__0()
at System.Data.Common.Utils.Memoizer`2.Result.GetValue()
at System.Data.Common.Utils.Memoizer`2.Evaluate(TArg arg)
at System.Data.Metadata.Edm.DefaultAssemblyResolver.<GetAlreadyLoadedNonSystemAssemblies>b__0(Assembly a)
at System.Linq.Enumerable.WhereArrayIterator`1.MoveNext()
at System.Data.Metadata.Edm.DefaultAssemblyResolver.GetAllDiscoverableAssemblies()
at System.Data.Metadata.Edm.DefaultAssemblyResolver.GetWildcardAssemblies()
at System.Data.Metadata.Edm.MetadataArtifactLoaderCompositeResource.LoadResources(String assemblyName, String resourceName, ICollection`1 uriRegistry, MetadataArtifactAssemblyResolver resolver)
at System.Data.Metadata.Edm.MetadataArtifactLoaderCompositeResource.CreateResourceLoader(String path, ExtensionCheck extensionCheck, String validExtension, ICollection`1 uriRegistry, MetadataArtifactAssemblyResolver resolver)
at System.Data.Metadata.Edm.MetadataArtifactLoader.Create(String path, ExtensionCheck extensionCheck, String validExtension, ICollection`1 uriRegistry, MetadataArtifactAssemblyResolver resolver)
at System.Data.Metadata.Edm.MetadataCache.SplitPaths(String paths)
at System.Data.Common.Utils.Memoizer`2.<>c__DisplayClass2.<Evaluate>b__0()
at System.Data.Common.Utils.Memoizer`2.Result.GetValue()
at System.Data.Common.Utils.Memoizer`2.Evaluate(TArg arg)
at System.Data.EntityClient.EntityConnection.GetMetadataWorkspace(Boolean initializeAllCollections)
at System.Data.Objects.ObjectContext.RetrieveMetadataWorkspaceFromConnection()
at System.Data.Objects.ObjectContext..ctor(EntityConnection connection, Boolean isConnectionConstructor)
at System.Data.Objects.ObjectContext..ctor(String connectionString, String defaultContainerName)
at Stoque.ECM.Modelo.Contexto..ctor() in D:\ECM 2.0\Stoque.ECM\Stoque.ECM.Modelo\Stoque.Modelo.Designer.cs:line 159
at Stoque.ECM.Servico.ServicoECM.ObterUsuarioPorLogin(String login) in D:\ECM 2.0\Stoque.ECM\Stoque.ECM.Servico\Classes\Usuarios.cs:line 331
I haven't idea about the problem...
I'll be glad about any help.
Thanks in advance
Looks like the culture of one of your assemblies is incorrect. For performance reasons by default Entity Framework filters out assemblies that most likely don't have entities like assemblies that are part of .NET Framework or assemblies that are shipped by Microsoft. Entity Framework is using public key token to filter these assemblies out. To get the public key token AssemblyName object is created using assembly.FullName. If the assembly.FullName is not a valid assembly name you will see the above exception.
Related
I'm attempting to create a Windows Runtime Component for use in a Windows 8 app.
This is essentially a helloworld level application and so has nothing complex. The only thing that I need to do to replicate the issue is to include a pair of methods such as the following:
public IAsyncOperation<string[]> GetThings()
{
return GetThingsAsync().AsAsyncOperation();
}
private async Task<string[]> GetThingsAsync()
{
return new List<string>().ToArray();
}
Whenever I compile the project, the Windows Metadata Exporter crashes.
I've dug into the errors generated in the output window by increasing the build verbosity and I've found that the error occurs after "Exporting 'obj\Debug\HelloWorld.Logic.winmdobj'."
By attempting to run winmdexp.exe from command line with the same parameters, it seems that it's having trouble finding metadata for the System.Xml files. (warning WME0004 : Could not find referenced metadata 'C:\Program Files(x86)\ReferenceAssemblies\Microoft\Framework.NETCore\v4.5.1\System.Xml.Serialization.dll'.)
The full stack trace of the error is:
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.Tools.WinMDExp.AssemblyReferenceExtensionMethods.IsWindowsRuntimeMetadata(IAssemblyReference assembly)
at Microsoft.Tools.WinMDExp.ExportVisitor.IsWindowsRuntimeType(ITypeReference type, Boolean allowGenericParam)
at Microsoft.Tools.WinMDExp.ExportValidator.<>c__DisplayClasse.<GetAlternativeTypes>b__8(<>f__AnonymousType0`2 <>h__TransparentIdentifier5)
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Collections.Generic.List`1.InsertRange(Int32 index, IEnumerable`1 collection)
at System.Collections.Generic.List`1.AddRange(IEnumerable`1 collection)
at Microsoft.Tools.WinMDExp.ExportValidator.GetAlternativeTypes(ITypeReference parameterType, IMethodDefinition containingMethod, Boolean& isTask, Boolean allowGenericTypeParam)
at Microsoft.Tools.WinMDExp.ExportValidator.GetAlternativesTypesForGenericTypes(IGenericTypeInstanceReference parameterType, IMethodDefinition containingMethod, String& errorMsg)
at Microsoft.Tools.WinMDExp.ExportValidator.CheckAlternateTypes(ITypeReference parameterType, IMethodDefinition containingMethod, Boolean& reportedError)
at Microsoft.Tools.WinMDExp.ExportValidator.ValidateExportParameterType(IMethodDefinition containingMethod, ITypeReference parameterType, Boolean& reportedError)
at Microsoft.Tools.WinMDExp.ExportValidator.ValidateExportMethod(IMethodDefinition method)
at Microsoft.Tools.WinMDExp.ExportValidator.TraverseChildren(IMethodDefinition method)
at Microsoft.Cci.MetadataTraverser.Traverse(IMethodDefinition method)
at Microsoft.Cci.MetadataTraverser.Traverse(IEnumerable`1 methods)
at Microsoft.Cci.MetadataTraverser.TraverseChildren(ITypeDefinition typeDefinition)
at Microsoft.Tools.WinMDExp.ExportValidator.TraverseChildren(ITypeDefinition typeDefinition)
at Microsoft.Cci.MetadataTraverser.TraverseChildren(INamedTypeDefinition namedTypeDefinition)
at Microsoft.Tools.WinMDExp.ExportValidator.TraverseChildren(INamespaceTypeDefinition namespaceTypeDefinition)
at Microsoft.Cci.MetadataTraverser.Traverse(INamespaceTypeDefinition namespaceTypeDefinition)
at Microsoft.Cci.MetadataTraverser.Dispatcher.Visit(INamespaceTypeDefinition namespaceTypeDefinition)
at Microsoft.Cci.MetadataReader.ObjectModelImplementation.NamespaceType.Dispatch(IMetadataVisitor visitor)
at Microsoft.Tools.WinMDExp.ExportValidator.Validate(ITypeDefinition type)
at Microsoft.Tools.WinMDExp.ExportValidator.TraverseChildren(IModule module)
at Microsoft.Cci.MetadataTraverser.TraverseChildren(IAssembly assembly)
at Microsoft.Tools.WinMDExp.ExportValidator.TraverseChildren(IAssembly assembly)
at Microsoft.Cci.MetadataTraverser.Traverse(IAssembly assembly)
at Microsoft.Tools.WinMDExp.ExportVisitor.Export(IAssembly assembly)
at Microsoft.Tools.WinMDExp.Exporter.Export()
at Microsoft.Tools.WinMDExp.Program.Main(String[] args)
If anyone has any idea what's going on and how I can get my component compiling I'd be grateful.
James
P.S. I transferred the project to a colleague's PC and they had the same issue so I doubt if it's anything to do with my setup (Windows 8.1 x64, Visual Studio 2013 Ultimate).
I've managed to figure this out myself.
It seems as though there is a bug when using string[] (or other arrays) as the generic type for IAsyncOperation.
I have managed to work around this because actually I will want to return IDictionary objects and ILists, which work fine:
/* //Won't Work - crashes Windows Metadata Exporter
public IAsyncOperation<string[]> GetThings()
{
return GetThingsAsync().AsAsyncOperation();
}
private async Task<string[]> GetThingsAsync()
{
return new [] {"I am a string"};
}
*/
//This Works
public IAsyncOperation<IList<string>> GetThingsList()
{
return GetThingsListAsync().AsAsyncOperation();
}
private async Task<IList<string>> GetThingsListAsync()
{
return new[] { "I am a string" };
}
Hopefully this will be of use to anyone else who comes across this weird behaviour.
I'm trying to use ServiceStack for Json serialization/deserialization in MonoDroid project.
I've built ServiceStack to run it in MonoDroid environment, but now I have issue with JSON deserialization.
Example code:
public class Track
{
public string Id { get; set; }
public string Title { get; set; }
public string Artist { get; set; }
public string Hash { get; set; }
public string Type { get; set; }
}
}
...
var track = new Track { Id = "1", Artist = "artist name", Hash = "654874", Title = "song title", Type = "mp3", };
var json = ServiceStack.Text.JsonSerializer.SerializeToString(track);
var track1 = ServiceStack.Text.JsonSerializer.DeserializeFromString<Track>(json);
On deserialization I have an exception:
Unhandled Exception:
System.ArgumentNullException: Argument cannot be null.
Parameter name: method
Stacktrace:
[External Code]
0x5E in ServiceStack.Text.Json.JsonReader.GetParseFn at [...]\Android\ServiceStack.Text\src\ServiceStack.Text\Json\JsonReader.Generic.cs:36 C#
0x2 in ServiceStack.Text.Json.JsonTypeSerializer.GetParseFn at [...]\Android\ServiceStack.Text\src\ServiceStack.Text\Json\JsonTypeSerializer.cs:283 C#
0xF in ServiceStack.Text.Common.TypeAccessor.Create at [...]\Android\ServiceStack.Text\src\ServiceStack.Text\Common\DeserializeType.cs:146 C#
0x142 in ServiceStack.Text.Common.DeserializeType`1[[ServiceStack.Text.Json.JsonTypeSerializer, ServiceStack.Text, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].GetParseMethod at [...]\Android\ServiceStack.Text\src\ServiceStack.Text\Common\DeserializeType.cs:60 C#
0x43A in ServiceStack.Text.Common.JsReader`1[[ServiceStack.Text.Json.JsonTypeSerializer, ServiceStack.Text, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].GetParseFn at [...]\Android\ServiceStack.Text\src\ServiceStack.Text\Common\JsReader.cs:100 C#
0x6 in ServiceStack.Text.Json.JsonReader`1[[Database.Models.Track, AssemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]..cctor at [...]\Android\ServiceStack.Text\src\ServiceStack.Text\Json\JsonReader.Generic.cs:58 C#
0x1B in ServiceStack.Text.JsonSerializer.DeserializeFromString at [...]\Android\ServiceStack.Text\src\ServiceStack.Text\JsonSerializer.cs:33 C#
As I see there is:
var genericType = typeof(JsonReader<>).MakeGenericType(type);
var mi = genericType.GetMethod("GetParseFn", BindingFlags.Public | BindingFlags.Static);
parseFactoryFn = (ParseFactoryDelegate)Delegate.CreateDelegate(typeof(ParseFactoryDelegate), mi);
genericType is "ServiceStack.Text.Json.JsonReader`1[System.String]"
type is "System.String"
So, there "mi" variable is null
Are any ideas how to fix it, or where to look?
Thanks.
The problem here was that you had linking enabled in your build configuration, and the GetParseFn() method was being linked away, as it wasn't explicitly being referenced.
The linker is a static analysis tool that is included as part of Mono for Android's build process. It will scan through your compiled application and actually strip out any pieces of .NET (or in this case, your compiled ServiceStack class library) that aren't explicitly being referenced. This goes a long way to cut down the size of your application, but you can run into problems, as seen here. Since the GetParseFn() method was never being explicitly referenced (it is being called via reflection), the linker had no idea it was needed and linked it away.
There are several ways you can handle this problem going forward.
Disable linking entirely: you can turn off linking in the project's properties. In general it's easier to leave it off for debug builds, and turn it on for release builds. This obviously isn't a full solution if you ever plan on doing a release build, of course.
Link only SDK assemblies: this option will tell the linker only to operate on the .NET BCL and Android SDKs, and will leave your libraries alone.
Use PreserveAttribute: Using this attribute you can tell the linker to leave in certain pieces that you know are required, even though they're not explicitly referenced. Since ServiceStack is an external library and not your own, this probably isn't the best solution in this case.
Use Linkskip: This option allows you to specify specific assemblies that shouldn't be touched by the linker, allowing you to leave the linker on but simply opt out when needed.
Personally, in your situation here I could suggest going the Linkskip route. It would allow you to still get all the benefits of the linker, but have it ignore ServiceStack to avoid problems like this. In your project file, you would end up with something along the lines of this:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<AndroidLinkMode>Full</AndroidLinkMode>
<AndroidLinkSkip>ServiceStack.Text</AndroidLinkSkip>
</PropertyGroup>
For various reasons I am trying to upgrade a project from an old version of Castle to v 2.5.3 (I cannot move to v3 due to breaking changes) and am encountering an issue with a generic component that is remoted:
Container.Register(Component.For(typeof(IStore<>))
.Named("GenericStore")
.AddAttributeDescriptor("remoteserver", "RecoverableComponent")
.AddAttributeDescriptor("marshalByRefProxy", "true")
.ImplementedBy(typeof(MyStore<>)));
The component appears to register OK, but at the point I attempt to resolve:
Container.Resolve<IStore<Users>>()
I get an exception "an item with the same key has already been added" and the stack trace (shortened):
at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at System.Collections.Generic.Dictionary`2.System.Collections.IDictionary.Add(Object key, Object value)
at Castle.Facilities.Remoting.RemotingInspector.ConfigureServerComponent(RemotingStrategy server, Type type, ComponentModel model)
at Castle.Facilities.Remoting.RemotingInspector.ProcessModel(IKernel kernel, ComponentModel model)
at Castle.MicroKernel.ModelBuilder.DefaultComponentModelBuilder.BuildModel(String key, Type service, Type classType, IDictionary extendedProperties)
at Castle.MicroKernel.Handlers.DefaultGenericHandler.GetSubHandler(CreationContext context, Type genericType)
at Castle.MicroKernel.Handlers.DefaultGenericHandler.ResolveCore(CreationContext context, Boolean requiresDecommission, Boolean instanceRequired)
at Castle.MicroKernel.Handlers.AbstractHandler.Resolve(CreationContext context, Boolean instanceRequired)
at Castle.MicroKernel.Handlers.AbstractHandler.Resolve(CreationContext context)
As you can see from the stack trace, it appears to be "building the model" (call to DefaultComponentModelBuilder) again.
Am I registering my component incorrectly?
I've downloaded some of the source code to try and find what I am doing wrong, but wonder if it is actually an issue caused by a combination of Generic and Remoting?
The exception is caused by Castle.Facilities.Remoting.RemotingInspector trying to add properties to the ExtendedProperties dictionary that alreadt exist. In Castle.MicroKernel.Handlers.DefaultGenericHander it doesn't appear to be detecting the fact that the model already exists (is it me or is nothing ever actually added to the Dictionary type2SubHandler?).
Can anyone tell me if I am doing anything wrong, or is there actually a bug?
My humble suggestion is that it is not a problem with Castle Windsor at all. Probably you have a static dictionary defined in the component that Castle Windsor tries to resolve which dictionary(or other collection with uniqe key constraint) has a diplicate key. Probably from copy-paste operation. you will get this error if you try to instantiate the class by hand. The code may look like this :
public class MissTypedDictionaryClass
{
... some ctors here
... some other methods and props
... and somewhere here lies the mistyped dict
private static readonly Dictionary<string, string> MyDeclaredDict = new Dictionary<string, string>()
{
{"Key1", "Val1"},
{"Key2", "Val2"},
{"Key1", "Val3"}, // Here is the problem.
};
}
I am trying to install MOSS 2007. This computer already had MOSS2007 installed, we had to uninstall MOSS2007 and install it again (for various reasons).
When we install MOSS2007, the installation completed fine but the Sharepoint Products and Technologies Configuration Wizard runs into the following problem in Step 2.
Why does it not work? What is the root cause/solution?
PS: I have SQL Server 2005 already installed on the machine.
The error message is as follows -
Failed to create the configuration database
An exception of type System.Security.Principal.IdentityNotMappedException was thrown. Additional exception information: Some or all identity references could not be translated.
The eventviewer has the stack trace -
Failed to create the configuration
database. An exception of type
System.Security.Principal.IdentityNotMappedException
was thrown. Additional exception
information: Some or all identity
references could not be translated.
System.Security.Principal.IdentityNotMappedException:
Some or all identity references could
not be translated. at
System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection
sourceAccounts, Type targetType,
Boolean forceSuccess) at
System.Security.Principal.NTAccount.Translate(Type
targetType) at
Microsoft.SharePoint.Administration.SPProcessIdentity.GetCurrentSecurityIdentifier()
at
Microsoft.SharePoint.Administration.SPProcessIdentity.GetCurrentSid()
at
Microsoft.SharePoint.Administration.SPProcessIdentity.Update()
at
Microsoft.SharePoint.Administration.SPApplicationPool.Update()
at
Microsoft.SharePoint.Administration.SPWebApplication.CreateDefaultInstance(SPWebService
service, Guid id, String
applicationPoolId, IdentityType
identityType, String
applicationPoolUsername, SecureString
applicationPoolPassword, String
iisServerComment, Boolean
secureSocketsLayer, String
iisHostHeader, Int32 iisPort, Boolean
iisAllowAnonymous, DirectoryInfo
iisRootDirectory, Uri defaultZoneUri,
Boolean iisEnsureNTLM, Boolean
createDatabase, String databaseServer,
String databaseName, String
databaseUsername, String
databasePassword,
SPSearchServiceInstance
searchServiceInstance, Boolean
isPaired, Boolean
autoActivateFeatures) at
Microsoft.SharePoint.Administration.SPAdministrationWebApplication.CreateDefaultInstance(SqlConnectionStringBuilder
administrationContentDatabase,
SPWebService adminService,
IdentityType identityType, String
farmUser, SecureString farmPassword)
at
Microsoft.SharePoint.Administration.SPFarm.CreateAdministrationWebService(SqlConnectionStringBuilder
administrationContentDatabase,
IdentityType identityType, String
farmUser, SecureString farmPassword)
at
Microsoft.SharePoint.Administration.SPFarm.CreateBasicServices(SqlConnectionStringBuilder
administrationContentDatabase,
IdentityType identityType, String
farmUser, SecureString farmPassword)
at
Microsoft.SharePoint.Administration.SPFarm.Create(SqlConnectionStringBuilder
configurationDatabase,
SqlConnectionStringBuilder
administrationContentDatabase,
IdentityType identityType, String
farmUser, SecureString farmPassword)
at
Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.CreateOrConnectConfigDb()
at
Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.Run()
at
Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()
You must delete the config database in SQl. But also make sure you delete the previous central admin site in IIS and delete the related app pool.
I'm pulling my hair out on this one. I'm trying to implement a ADO.Net Data Service that uses a Linq to SQL data context. I thought I had it working, but the URL for one of my tables always gets an exception.
The obvious difference between the table that isn't working and the ones that are, is that the one getting the exception is using a Guid, which is the primary key. The Guid is a UserID, which actually relates to the UserId used by ASP.net Membership. (I'm not exposing the ASP.net Membership tables, but I'm guessing these would break too if I were.)
It is a very simple table:
Name: UserDetails :: | Guid UserID | int GroupID (foreign key) | string Name |
Anybody know if there's a trick to getting Guids to work? Or if maybe this is an entirely different problem?
Here's the exception from the service:
An error occurred while processing this request.
InnerError: An error occurred while processing this request.
Type: System.InvalidOperationException
StackTrace:
t System.Data.Services.Serializers.SyndicationSerializer.WriteComplexObjectValue(Object element, String propertyName, ResourceType expectedType, String relativeUri, DictionaryContent content)
at System.Data.Services.Serializers.SyndicationSerializer.WriteObjectProperties(IExpandedResult expanded, Object customObject, ResourceType resourceType, Uri absoluteUri, String relativeUri, SyndicationItem item, DictionaryContent content)
at System.Data.Services.Serializers.SyndicationSerializer.WriteComplexObjectValue(Object element, String propertyName, ResourceType expectedType, String relativeUri, DictionaryContent content)
at System.Data.Services.Serializers.SyndicationSerializer.WriteObjectProperties(IExpandedResult expanded, Object customObject, ResourceType resourceType, Uri absoluteUri, String relativeUri, SyndicationItem item, DictionaryContent content)
at System.Data.Services.Serializers.SyndicationSerializer.WriteComplexObjectValue(Object element, String propertyName, ResourceType expectedType, String relativeUri, DictionaryContent content)
at System.Data.Services.Serializers.SyndicationSerializer.WriteObjectProperties(IExpandedResult expanded, Object customObject, ResourceType resourceType, Uri absoluteUri, String relativeUri, SyndicationItem item, DictionaryContent content)
at System.Data.Services.Serializers.SyndicationSerializer.WriteEntryElement(IExpandedResult expanded, Object element, Type expectedType, Uri absoluteUri, String relativeUri, SyndicationItem target)
at System.Data.Services.Serializers.SyndicationSerializer.<DeferredFeedItems>d__0.MoveNext()
at System.ServiceModel.Syndication.Atom10FeedFormatter.WriteItems(XmlWriter writer, IEnumerable`1 items, Uri feedBaseUri)
at System.ServiceModel.Syndication.Atom10FeedFormatter.WriteFeedTo(XmlWriter writer, SyndicationFeed feed, Boolean isSourceFeed)
at System.ServiceModel.Syndication.Atom10FeedFormatter.WriteFeed(XmlWriter writer)
at System.ServiceModel.Syndication.Atom10FeedFormatter.WriteTo(XmlWriter writer)
at System.Data.Services.Serializers.SyndicationSerializer.WriteTopLevelElements(IExpandedResult expanded, IEnumerator elements, Boolean hasMoved)
at System.Data.Services.Serializers.Serializer.WriteRequest(IEnumerator queryResults, Boolean hasMoved)
at System.Data.Services.ResponseBodyWriter.Write(Stream stream)
That looks like a bug. I suggest you report it at http://connect.microsoft.com/visualstudio/, then post the URL of your bug report here, so we can vote on it.
I found the fix to my problem. It actually wasn't related to using a Guid value at all.
I had to add an [IgnoreProperties("User")] to my UserDetail class in Linq to SQL.
The "User" Property is a relation to the "User" class that holds the ASP.Net Memberships user informations (actual table name is aspnet_Users). I have the Linq to SQL "User" class ignored by the data service so I think this must have been the problem.
What threw me way off was that the data service wasn't throwing any errors when I accessed it. With all the other properties, where I either had to add a DataServiceKey() or IgnoreProperties() decoration, when I accessed DataService.svc, I would get an exception complaining about the problem property. For whatever reason, it didn't give me a problem with this one property though, so I wasn't aware anything was wrong. And as you can see above, when I did get an exception, it wasn't useful.
So to any others using Linq To SQL with ADO.Net Data Services, this is the lesson:
Make sure you use IgnoreProperties() on any property that references a class you are ignoring.