I have to work with a project I didn't wrote myself. It uses Ecore EMF (I have no experience with this) and I can't figure out how to solve this error:
At some point the program loads a .xmi file with this function: org.eclipse.emf.ecore.xmi.impl.XMLHandler.getPackageForURI()
And this results in this error:
org.eclipse.emf.ecore.xmi.PackageNotFoundException: Package with uri 'platform:/plugin/Animals/model/Animals.ecore' not found. (file:/C:/Users/model917.xmi, 2, 193)
It seems like the file model917.xmi exists and is not the origin of this error. I think the problem is caused because the Animals.ecore file is not found. In the model917.xmi file I found this statement:
xmlns: Animals ="platform:/plugin/Animals/model/Animals.ecore
So I think the model in file model917.xmi uses another model defined in Animals.ecore which can't be found and causes the error.
I have access to the Animals.ecore file and found out that EMF/ecore uses something like a registry to find such files. So it seems like I have to add the Animals.ecore file to this registry and I found some answers online which didn't work and I run out of ideas what to try next. Can someone give me an easy way to register this file so it will be found? I am using Eclipse if this is relevant/maybe there is an easy way to do it with Eclipse.
Usually, EMF-based softwares should rely on the so-called "namespace URI" (nsURI) of EPackages, which are usually of the form "http://foo/bar/Animals".
"http://foo/bar/Animals" should be registered in the EMF Registry and dispatch depending on your actual runtime situation to a URI that looks like "platform:/plugin/bar.foo/Animals.ecore" (when file Animals.ecore is deployed in an Eclipse plugin for an Eclipse-based application), or "platform:/resource/bar.foo/Animals.ecore" (when file Animals.ecore is deployed in the workspace of the running Eclipse-based application) or even "file:///path/to/Animals.ecore" (anywhere on the filesystem).
Technically you can use any of those URI forms as long as they are correctly resolved at runtime, but you must understand that not all URIs make sense in all contexts, for instance "platform:/" URIs only make sense in Eclipse-based context. nsURIs are supposed to be resolveable in all contexts (thanks to the registry!)
Is your code meant to be running in the context of an Eclipse-based application ? Then the project containing Animals.ecore should be deployed as a plugin, and I am guessing it is currently not.
Is your code meant to be standalone? Then the reference in your xmi file, to the ecore file, should not be of the form "platform:/..." but rather of the form "http://foo/bar/Animals" (the nsURI of the EPackage that is the root element of Animals.ecore)
Related
I moved a web application I am working on from one machine to another. It is built using .Net MVC and Entity Framework but when I execute the Update-Database command so that the database is updated, I get this error:
Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "NameofMigration.resources" was correctly embedded or linked into assembly "NameofProject" at compile time, or that all the satellite assemblies required are loadable and fully signed.
Does anyone know how to fix this error?
I had a similar issue when the resx part of the migration was not included in the project file when a fellow developer checked the project in (probably due to a merge issue). You may find that the resx file is there but greyed out. If it's there, try right clicking the "NameofMigration.resx" file and selecting "include in project". If it's not there, you better go find it on the other machine and add it to the project :-)
I think the issue (one issue) is that the .resx file is added as "dependent upon" (nested under) the .cs file, and the way the build engine works, "dependent upon" changes the name that an embedded resource is saved with (something like, it changes from being based on the filename to being based on the type name; I've dealt with this in other scenarios but can't remember for sure).
This leads to problems when using SDK .csproj files, for some reason (I guess that by default SDK .csproj does not change the resource name in this situation, but the migrations system expects it to).
As someone else had posted, SDK .csproj can use the following tag to change the embedded resource naming scheme for "dependent upon" resources, which then allows the migrations system to find the embedded resource:
<EmbeddedResourceUseDependentUponConvention>
true
</EmbeddedResourceUseDependentUponConvention>
This should go in a <PropertyGroup> of your SDK .csproj file.
For VS 2017, the solution is as follows:
Go to the project file, and for all of the migrations, apply the following format:
<Compile Include="Migrations\201804251606403_emailsWithEffort.cs" />
<Compile Include="Migrations\201804251606403_emailsWithEffort.Designer.cs">
<DependentUpon>201804251606403_emailsWithEffort.cs</DependentUpon>
</Compile>
<EmbeddedResource Include="Migrations\201804251606403_emailsWithEffort.resx">
<DependentUpon>201804251606403_emailsWithEffort.cs</DependentUpon>
</EmbeddedResource>
I guess that the problem is when changing version(s) of Visual Studio, old format of describing dependencies stays, and the Visual Studio 2017 can not interpret it correctly.
Hence, applying the format as described above (change your format to this), you can make the Visual Studio get the idea of where it's resources are.
Slightly different situation, where I created a new environment, and database, and received the above error message.
For my fix, I had to right-click on the migration files (initial and resx) and set property to embedded as resource. Update-database command ran fine afterward.
I encountered the same issue (VS 2017) and none of the solutions provided here worked. I fixed the problem by cleaning the solution and manually deleting the bin folder and then building it again.
If anybody wants to look into the source or compiler to know why this is happening; I don't feel like it right now. After an hour of tinkering, my resolution is odd.
Granted, I shouldn't have done this in the first place, but for quick code I temporarily added classes into the same file as my generated DbMigration 201906212110305_initial.cs. The mere existence of those temporary classes in the same file caused this error. As soon as I moved them to their own file (which I was going to do all along anyway) the runtime error vanished.
Unloading and then reloading migration file worked for me!
I am currently debugging a web application which uses a drools ruleset inside an EJB to process business rules. It's deployed inside a JBoss server. I've configured eclipse to run the server so I could use Debug on Server functionality of eclipse.
When I reach the class that fires the drools ruleset, the server loses focus and returns after all the rules are fired. Is there a way where I could trace what rules are being fired? Right now, what I do is put logs inside the *.drl files so I know where the application is inside the rules engine.
you can get the generated java source code of any rule when you add a file with name drools.packagebuilder.conf to your %USERHOME% directory.
The file must contain the following instruction:
drools.dump.dir = d:/myDroolsJavaSourceCode
The directory d:/myDroolsJavaSourceCode - Directory (or any other given name) must exist otherwise the Drools Packagebuild will stop execution.
Then you can add this directory to your Eclipse Environment as new project (probably you have to remove the flag 'Default Location' to choose the 'myDroolJavaSourceCode').
Then you can open the file in Eclipse and set break points in the editor.
May be you must attach the directory also during debugging execution twice.
Best regards!
Christof
As far as I know you can't debug drl file. What we did was to encapsulate the logic of when and then in a method, so that you can at least debug that.
Maddy
What I did is I downloaded the sources for drools-engine and compiled the drl files to their java sources. When you run the app, you'll have an option to attach sources when the break point reaches the engine. It's still hard to trace the rules that are fired (multiple rules from different drls can be fired) but it's better than just sysout logging.
I'm currently working on an shared library based on mono, where I want to put as much business logic of my app as possible.
I used this helpful tutorial.
I managed putting the whole logic for rest-requests in this shared library, but now I'm stuck with soap.
I used the wsdl command of mono to generate Client Stubcode from my wsdl (as described here http://www.mono-project.com/Web_Services).
When I put the generated class to my C# library, which is the root project of my shared library, there is a warning that the Reference to System.Web.Services cannot be found.
So I included the System.Web.Services.dll manually.
For the Android Library Project I added a Reference to ...\Reference Assemblies\Microsoft\Framework\MonoAndroid\v1.0\System.Web.Services.dll. It compiles without warnings.
But now it comes to the Windows Phone Library Project.
There is no System.Web.Services.dll for WP 7.5, right? I tried with the Mono-Touch dll but it gives me a lot compilation Errors.
Someone knows how I can get out of this?
I actually had some issues with the generated WSDL myself. Turns out that the classes that were generated through the "Create Web Reference" piece of Visual Studio inside of a Mono for Android project ended up causing some big issues when connected to a WCF Web Service. Not sure where I ran into this information, but this is what I ended up doing.
What you need to do is manually create a Service Reference using the SILVERLIGHT SVCUtil.
On my development system it was located here:
C:\Program Files (x86)\Microsoft SDKs\Silverlight\v3.0\Tools
I called it with the below command line:
slsvcutil.exe http://localhost/<path to WCF service endpoint>/service.svc /directory:"<temp directory to store generated cs file>" /noConfig /namespace:"*,<Full namespace of the generated class>"
That will actually generate a CS file that is saved into the path specified by the /directory tag above. Copy that generated cs file to your project directory and then include it in the project.
The problem that I was having that forced me to look for another option was that I was able to pull the data properly using the WSDL generated through the "Add Web Reference" option in Visual Studio, but as soon as I tried to pass the data back up the wire to the web service, everything blew up. Using the Service Reference generated by the Silverlight Service Util actually generated all the code properly for Async operations and after learning how to properly manage those Async operations everything works like a dream.
Since you are generating this new WSDL using the Silverlight Utility, it should work just fine through Windows Phone 7. I believe that the DLL to reference for all of this is the System.ServiceModel dll.
I wish I could remember where I ran across this information, as I would like to give the original author credit, but unfortunately, I don't recall that.
Hope that helps out!
Chaitanya Marvici
I want to use a external jar (Apache Mahout) on the server side of my GWT Applicatopn.
As far as i know using external jars on the server side shouldn't cause an error. Only on the client side but when i try to run the code i get the following error:
"no source code is available for de.unimannheim.paniscus.server..."
Whats wrong here ?
Please help me i need to solve this for my thesis
Hi guys i created now an collbaorative.gwt.xml where i inherited all classes from apache mahout that are used within de.unimannheim.paniscus.server.collaborative but it's still not working. Sorry i'm helpless whats wrong here ?
I agree with Dusty Campbell, you should not inherit the jar in the *.gwt.xml. The <inherits> tag in the *.gwt.xml specifies gwt-modules which should be inherited. So only client-side-compatible code can be inherited.
Citation from the gwt docs: "<inherits name="logical-module-name" /> : Inherits all the settings from the specified module as if the contents of the inherited module's XML were copied verbatim. Any number of modules can be inherited in this manner"
see also: http://code.google.com/webtoolkit/doc/1.6/DevGuideOrganizingProjects.html#DevGuideInheritingModules
My guess is that you (by mistake) use a class from the "de.unimannheim.paniscus.server" package in client-side or shared code. Even just an import statement (import de.unimannheim.paniscus.server.*) will cause this exception.
I have a Solution which contains a Web project and a Class Library project. The Class library project contains Enterprise library 5.0 and app.config. When I try to perform a Microsoft.Practices.EnterpriseLibrary.Logging.Logger.Write, I get the following exception:
Resolution of the dependency failed,
type =
"Microsoft.Practices.EnterpriseLibrary.Logging.LogWriter",
name = "(none)". Exception occurred
while: while resolving. Exception is:
InvalidOperationException - The type
LogWriter cannot be constructed. You
must configure the container to supply
this value.
----------------------------------------------- At the time of the exception, the
container was: Resolving
Microsoft.Practices.EnterpriseLibrary.Logging.LogWriter,(none)
If I move all the class files to the web project and have the Enterprise library configuration in the Web.config, everything works fine. I guess the issue is that the Enterprise library is not detecting the app.config which contains all the configuration.
Kindly help me with this regard.
Thanks in advance.
.NET dlls don't have config files. AppDomains do. You cannot put any configuration in a dll's "app.config" file and expect it to get automatically picked up. This is the way .NET config files work; it's not that "entlib is not automatically detecting" it, it's doing what the .NET framework defines the behavior of config files to be.
The answer is to leave the code in the library, but put the configuration in the web app's web.config file. Then everything will just work.
There are more advanced things you can do like manually loading the config file, but they're fairly advanced and, particularly with logging, can cause admin headaches later.