Trying to change URLs
from:
http://blah/ReportServer
to:
http://blah/ReportServer/Foo
Error:
Microsoft.ReportingServices.WmiProvider.WMIProviderException: The virtual directory specified is not valid. Make sure the specified name is not too long and doesn't contain illegal characters. (example: ;)
---> System.Runtime.InteropServices.COMException (0x8004020D): Cannot modify or delete an object that was not added using the COM+ Admin SDK (Exception from HRESULT: 0x8004020D)
--- End of inner exception stack trace ---
at Microsoft.ReportingServices.WmiProvider.RSWmiAdmin.ThrowOnError(ManagementBaseObject mo)
at Microsoft.ReportingServices.WmiProvider.RSWmiAdmin.SetVirtualDirectory(String application, String virtualDirectory)
at ReportServicesConfigUI.WMIProvider.RSReportServerAdmin.SetVirtualDirectory(UrlApplication app, String virtualDirectory)
Changing to:
http://blah/ReportServer_Foo
works just fine. Not sure what's going on. Any information is appreciated.
Looks like its following the convention of SERVERNAME_INSTANCENAME used commonly with integrated authentication for example.
Related
I'm working on a project and I become always an Exception "TypeInitializationException".
I tried to give a string to a global string variable but it failed.
That's the code for the viewmodel and it failed on the second line
| {State = _}, ConsumablesClicked vm ->
Testtyp <- vm.TrackPosition.ToString()
That's on the other program
let mutable Testtyp = ""
I become this InnerException "Cannot read keys when either application does not have a console or when console input has been redirected from a file. Try Console.Read.".
"The type initializer for '.$BarcodeGenerieren' threw an exception.", that's the exception explication.
Has someone a Idea how solve this?
That exception indicates that some code is trying to call Console.ReadKey when the standard input for that process has been redirected (see e.g. Allowing redirection of StandardInput of a C# application when doing "Console.ReadKey"). The solution is not to call Console.ReadKey, but it's not clear from your description where this is actually happening (perhaps in the static constructor for one of your types?).
I found the solution after a lot of try and it was only, that I had a Console.Readkey in my code, that I forgot to delete.
I had before a console apllication and I transformed it to be a class.
using EF4
I atempt to make a connection but get this error message
"Entity Exception Message At least one of the input paths is not valid because either it is too long or it has incorrect format."
This used the example from http://msdn.microsoft.com/en-us/library/bb738533.aspx but passing in my own server name. What is the "input paths"
When I run it from a web app its fine, when I try and run it in a unit/integration test passing in the connection (as app.config might not be there) I get this error.
Whats going on?
I had the same issue. I was writing the code in the following way
ebuilder.Metadata = #"Model1.csdl, Model1.ssdl,Model1.msl";
Then after some research I changes it to
ebuilder.Metadata = #"res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl";
The magic happened and it started working.
I had same error in EF6. when I try to fetch something from DB, this error was thrown.
I solved this problem with correcting the MetaData part of my connectinString.
you must have MetaData part like below:
metadata=res:///myModel.csdl|res:///myModel.ssdl|res://*/myModel.msl;
Having a StorageFolder object and trying to create a folder with a name that contains a colon somewhere inside (not at the beginning or the end) results in a COM error with HRESULT 80004005 (HRESULT E_FAIL).
Example:
await ApplicationData.Current.TemporaryFolder.CreateFolderAsync("abc:xyz",
CreationCollisionOption.OpenIfExists);
If the colon is at the beginning ot at the end I get a HRESULT 8007007b with the message "The filename, directory name, or volume label syntax is incorrect". That's fine.
I checked with other invalid chars but only a colon leads to E_FAIL.
This may be a problem if the user enters the folder name. Workaround is of course to simply check for a colon in the filename.
Does anyone know a possible reason for the E_FAIL error? I assume that COM thinks the foldername starts with an URI but can of course not figure out what kind of URI it is.
Well, COM's infamous error reporting is back with a vengeance. We've gotten spoiled from years of .NET's excellent and informative exceptions but that rug got pulled by WinRT. COM is the underlying interop mechanism and HRESULTs are the way errors get reported.
E_FAIL is the canonical error code, the only descriptive text you can get with that is "Unspecified error". Which is accurate, the Microsoft programmer that handled that code could not or did not want to produce a more descriptive error. Another great doozy is E_UNEXPECTED, it translates to "Catastrophic failure". The term "catastrophic" really refers to the value of the error message if you ever get it.
Speculating somewhat, the "abc:xyz" path string is actually valid. It refers to an alternate data stream named "xyz", stored in file "abc". So checking the path string isn't going to raise a stink, at first. You are however creating a folder by that name, not a file. A folder cannot have an alternate data stream. Apparently this is discovered very late, too late to still produce a more accurate error code. It should have produced a Windows error and they are wrapped appropriately in a HRESULT by or-ing it with 0x8007000 but that wasn't done for unguessable reasons.
No way to send feedback about this, the Windows group doesn't have the equivalent of DevDiv's connect.microsoft.com. Good thing you know what caused the error.
Scenario: I am using Managed Extensibility Framework to load plugins (exports) at runtime based on an interface contract defined in a separate dll. In my Visual Studio solution, I have 3 different projects: The host application, a class library (defining the interface - "IPlugin") and another class library implementing the interface (the export - "MyPlugin.dll").
The host looks for exports in its own root directory, so during testing, I build the whole solution and copy Plugin.dll from the Plugin class library bin/release folder to the host's debug directory so that the host's DirectoryCatalog will find it and be able to add it to the CompositionContainer. Plugin.dll is not automatically copied after each rebuild, so I do that manually each time I've made changes to the contract/implementation.
However, a couple of times I've run the host application without having copied (an updated) Plugin.dll first, and it has thrown an exception during composition:
Unable to load one or more of the requested types. Retrieve the LoaderExceptions for more information
This is of course due to the fact that the Plugin.dll it's trying to import from implements a different version of IPlugin, where the property/method signatures don't match. Although it's easy to avoid this in a controlled and monitored environment, by simply avoiding (duh) obsolete IPlugin implementations in the plugin folder, I cannot rely on such assumptions in the production environment, where legacy plugins could be encountered.
The problem is that this exception effectively botches the whole Compose action and no exports are imported. I would have preferred that the mismatching IPlugin implementations are simply ignored, so that other exports in the catalog(s), implementing the correct version of IPlugin, are still imported.
Is there a way to accomplish this? I'm thinking either of several potential options:
There is a flag to set on the CompositionContainer ("ignore failing imports") prior to or when calling Compose
There is a similar flag to specify on the <ImportMany()> attribute
There is a way to "hook" on to the iteration process underlying Compose(), and be able to deal with each (failed) import individually
Using strong name signing to somehow only look for imports implementing the current version of IPlugin
Ideas?
I have also run into a similar problem.
If you are sure that you want to ignore such "bad" assemblies, then the solution is to call AssemblyCatalog.Parts.ToArray() right after creating each assembly catalog. This will trigger the ReflectionTypeLoadException which you mention. You then have a chance to catch the exception and ignore the bad assembly.
When you have created AssemblyCatalog objects for all the "good" assemblies, you can aggregate them in an AggregateCatalog and pass that to the CompositionContainer constructor.
This issue can be caused by several factors (any exceptions on the loaded assemblies), like the exception says, look at the ExceptionLoader to (hopefully) get some idea
Another problem/solution that I found, is when using DirectoryCatalog, if you don't specify the second parameter "searchPattern", MEF will load ALL the dlls in that folder (including third party), and start looking for export types, that can also cause this issue, a solution is to have a convention name on all the assemblies that export types, and specify that in the DirectoryCatalog constructor, I use *_Plugin.dll, that way MEF will only load assemblies that contain exported types
In my case MEF was loading a NHibernate dll and throwing some assembly version error on the LoaderException (this error can happen with any of the dlls in the directory), this approach solved the problem
Here is an example of above mentioned methods:
var di = new DirectoryInfo(Server.MapPath("../../bin/"));
if (!di.Exists) throw new Exception("Folder not exists: " + di.FullName);
var dlls = di.GetFileSystemInfos("*.dll");
AggregateCatalog agc = new AggregateCatalog();
foreach (var fi in dlls)
{
try
{
var ac = new AssemblyCatalog(Assembly.LoadFile(fi.FullName));
var parts = ac.Parts.ToArray(); // throws ReflectionTypeLoadException
agc.Catalogs.Add(ac);
}
catch (ReflectionTypeLoadException ex)
{
Elmah.ErrorSignal.FromCurrentContext().Raise(ex);
}
}
CompositionContainer cc = new CompositionContainer(agc);
_providers = cc.GetExports<IDataExchangeProvider>();
This might seem obvious but I've had this error when trying to use LINQ to SQL with my business logic in a separate class library project.
I've created the DBML in a class library, with all my business logic and custom controls in this project. I'd referenced the class library from my web project and attempted to use it directly from the web project.
The error indicated the login failed for my user name. My user name and password were correct, but the fix was to copy my connection string to the correct location. I've learned the issue from another site and thought I would make a note here.
Error:
Login failed for user 'username'
System.Data.SqlClient.SqlException
The LINQ designer ads the connection string to the app.config of the class library, but the web site needed to see it in the web.config of the web project. Once copied across all was well.
you can pass in a connection or connection string to the data context as well.