I made my NServiceBus solution and it was all working. I then moved one of the projects to a different solution.
When I run them in that solution I get this error:
No endpoint configuration found in scanned assemblies. This usually happens when NServiceBus fails to load your assembly contaning IConfigureThisEndpoint.
I have a class in the project I am trying to get running that looks like this:
public class EndpointConfig : IConfigureThisEndpoint, AsA_Server
{
}
I fully copied the folder that contained this project when I moved it to the new solution. (So this is the exact same class that is in the original and the original worked perfectly.)
I am not sure what to do, so I did a bit of googling and came up on this question.
Based on the answer there, I have tried this:
Make sure that there is a class that implements IConfigureThisEndpoint
Make sure that only one class implements IConfigureThisEndpoint
Make sure that the NServiceBus libraries I am using are .NET 4 libraries
Make sure that the implementing class is public (see code above)
I don't do any non-default actions with regards to signing so delay-signing should not be an issue
Any ideas what would cause this error (besides what I have tried) would be great!
UPDATE:
I remembered that I had used the Modeler to setup the dependencies in the original project and NuGet to do it in the copied project.
So I went and compared versions. The Modeler based project was using NServiceBus 2.5.0.1496. When I used NuGet to upgrade that to NServiceBus 2.6.0.1505 (what I had in my copied project) I started getting the same error (in my original project that had previously worked just fine).
So I copied the working DLLs into my broken project and it all started working.
So I can only conclude that this is a version issue. Something with how I have set things up (defaults for the Modeler) is not compatible with version 2.6 of NServiceBus.
NuGet does not have history of the same version of NServiceBus as the Modeler tools has. I think this is an error because NServiceBus packages don't reset the build (last) number. And there is a NServiceBus version
2.6.1496,
but not a
2.5.1496
like what comes with the modeler (there is a 2.5.0.1490, but close only counts in horseshoes and hand grenades).
So I am going to have to abandon NuGet for NServiceBus (because I need the exact version that is in the Modeler or I have to figure out why I am getting this error.)
If anyone has a better way to deal with this problem I would LOVE to hear it.
I remembered that I had used the Modeler to setup the dependencies in the original project and NuGet to do it in the copied project.
So I went and compared versions. The Modeler based project was using NServiceBus 2.5.0.1496. When I used NuGet to upgrade that to NServiceBus 2.6.0.1505 (what I had in my copied project) I started getting the same error (in my original project that had previously worked just fine).
So I copied the working DLLs into my broken project and it all started working.
So I can only conclude that this is a version issue. Something with how I have set things up (defaults for the Modeler) is not compatible with version 2.6 of NServiceBus.
NuGet does not have history of the same version of NServiceBus as the Modeler tools has. I think this is an error because NServiceBus packages don't reset the build (last) number. And there is a NServiceBus version
2.6.1496, but not a
2.5.1496
like what comes with the modeler (there is a 2.5.0.1490, but close only counts in horseshoes and hand grenades).
So I am going to have to abandon NuGet for NServiceBus (because I need the exact version that is in the Modeler or I have to figure out why I am getting this error.)
Related
I have downloaded fresh Mulesoft studio and changed configuration to point Open JRE- 11 and compiler to point 11.
Studio version - 7.8
When I try creating the mule project it is now also adding module-info.java along with mule.xml files.
Wonder why it is creating module-info.java I don't used to see when i was working with 1.8 version or before.
Any Idea ?? Thanks in advance.
Java 9 introduced a whole new level of encapsulation. Larger than packages, and more robust too. These are modules.
Chances are you should in the long term, migrate your project to use modules (for additional security, and for better code organization). However, the chances are also high that you won't want to do it right now, just because.
In that latter case, it would be reasonable to simply delete the module-info.java file. Provided you don't have any other module-info.java files in the system, and provided you run with everything on the classpath rather than module path (there's a good chance that's your default anyway) you should not have any problem.
Meanwhile, you have some homework to do, so you can decide if you will migrate to modules, and if so, how to do it.
Pentaho Data Integration 8.0.x is using Janino 2.5.16, released in 2010 for compiling the User Defined Java Class step. There is a JIRA in pentaho for updating this to use a newer Janino version which would bring new java 8 related features in pentaho v8.2.0 GA. But there is no info on when will this be released.
Is there any other way I can use a newer janino version (janino-3.0.8.jar) with exiting pentaho for UDJC? I tried to copy updated jar in the lib and also added commons-compiler-3.0.8.jar to fulfill dependency. Now when I open Spoon, I get the following error:
Please advise on how this can be achieved. I understand that just replacing the jar may not be enough but just want if something else can be done.
This is not easy. Even now, since you got ClassNotFound, public api of janino is changed. Some classes are removed some are changed. What is actual needs to update it?
If you need really complicated business logic, then create custom plugin. Documentation and tutorials are available and you can look into sources of current builtin plugins (sources are available on github).
What important new version of janino has, that old doesn't (beside java8 support)? Checkout kettle engine, look into sources of UserDefinedClass step, change code to support new janino version, test and make own build of pdi kettle, and try to send push request to maintainers of repository.
Any of this quite complicated, This plugin is builtin into engine, and you have to make own build. Own build means, you have to support it by yourself. This is non trivial, project is huge and now even bigger and continue evolving, I spent several days to make my first custom build (version of 4, was in ivy) just for purpose to know better and debug complicated cases, and it used never in production.
Maintainers of repository must have good reason to include your changes into stream, it must be well tested and it is long procedure and most probably doesn't worth it. A lots of changed since 2010, I probable have seen in release notes, new version of java already have abilities to compile at runtime.
My advice is to make you own plugin.
I'm using Mule Server 3.8 EE which brings commons-lang 2.4 with it. A third-party library in my project needs commons-lang 2.6, because it uses a method that was introduced in this version.
So when I just start my application, I get a java.lang.NoSuchMethodError
Is there a way to update the dependency in the runtime? What I tried so far:
including commons-lang 2.6 in my app -> no effect, the one from the runtime is picked up first
replacing the jar directly in the runtime -> errors in studio, that the 2.4 jar is missing
so maybe i am late BUT -- this is your answer. Add the libraries that are newer in the jar distribution to the Build Path. Under Java Build Path screen you should see the libraries listed. I needed to use Apache http-client 4.5.6 and that's very interesting because it brings with it a lot of other dependencies, so your question was VERY relevant. The solution is to rely on JAVA (and not mule -- oops Anypoint or whatever) conventions and make sure the JVM loads my class files first. Then, it won't load the old ones from mule's jar. And so I went to the tab Order and Export, and moved Mule to the bottom. This simple, trivial change makes it work. I think if we would work with command line and vim, we would all know this. But all the IDE gui and everything else makes us forget the simplest things. Please use it in good health. :)
I am looking at nuget for improving automatic handling of dependencies (both internal and third party) during development.
A long as you develop through the CI Build Server, all is good:
get latest source for A and B, where B depends on A
fix bug in A
build A
check into source control
CI Build Server initiated
new nuget package is created and placed in corporate repository
build B (which will get the updated A package)
run B to verify that the bug in A was fixed
n. repeat n times
However, I'm wondering if it is possible to work locally as a single developer, without having to wait for the CI Build Server to produce a new package?
Nuget has a feature Package Restore, which will download all dependencies automatically on build. You can also list the repository order that the Package Restore should look for packages.
If the workflow could become:
get latest source for A and B, where B depends on A
fix bug in A
build A
(building creates a local nuget package)
run B to test the (resolved) bug in A (should now use our local nuget package, not local repository)
...repeat n times
check into source control
CI Build Server initiated
new nuget package created in corporate repository
Is this possible using Visual Studio, MSBuild, a CI Build Server and nuget? I'm especially interested in the making of local packages while developing locally.
Note that I have native projects, although except the generation of nuget package post-build, this would be a workflow that I hope should work for both C# and C++ projects.
The solution I have now, though far from ideal, is what I could figure out works best. Oh! and it is a work in progress so it WILL change in the coming weeks/months as I figure out how to get around the kinks.
I mostly have to deal with managed DLL right now but I do have some native code and worst, multi-platform native code to deal with eventually.
Create a local repository, basically just a folder and configure it in your list of nuget feeds.
Then I created a task (MSBuild) that will package the project and output it in the local repository's root folder. Make sure the version of your package is always increasing. Presently I do this manually by editing the assembly version.
Once built, update your other projects that reference it, I usually do this though the package manager console (update-package).
Each projects that was updated, bump up their version rinse lathe and repeat until you get to your top-most project (the actual program).
Once everything is nice and good and you are ready to commit then the build system should do it's own packaging and send it to your official repository.
The Good
No clogging of the repository and build system with intermediary development versions, that garbage remains (as it should) local.
Local repos are super easy to set-up, can even be done without changes to VS though the global nuget config.
This is friendly to both paradigms of package recover or checking-in packages with the project. That said I would recommend not checking in the packages you built locally but rather one that was committed to your local repository ideally through the build system. What's built local should remain local.
The Bad
Still much more complicated than just adding projects to a solution.
The deeper (or wider) your dependency tree the bigger the pain.
The Ugly
Makes some native nuget behaviors quite quirky and annoying :
Update operation takes forever if your VS is connected to a version system (perforce for me). I hear they "solved" the problem, would hate to see how it was before if it was worst that it is now !
Having nuget change non-code reference back to never copy is a major pain.
If Only
Configure the desired state of a content dependency (copy always, never or newer) directly from the nuspec and be done with it ! (oh and same story with ClickOnce content status include, exclude etc)
Make the update operation quick, 2 minutes for a dozen project is just insane, especially if the ultimate goal is to manage 500+.
Perhaps a hybrid mode where locally we work with projects inclusion but the build system would work with nuget dependency (and build them if necessary)
If you are to parse the project do follow MSBuild parsing rules and honor the conditional statements.
There are still issues I have yet to figure out like how to manage multiple branches of the code in the repository. How to handle version conflict further up the food chain. In a large project (ultimately we have to bring 500+ separate projects together in a single application executable, conflicts are expected).
I would love to bring all the goodness of sane dependency management à la Maven but thus far I did not find nuget to be mature enough to even think of proposing it to the dev team.
Certainly. In our solutions, NuGet parks the libraries in the "packages" directory of the solution's hierarchy which is ultimately kept in TFS. This allows for complete solution check-outs that includes the required libraries. If it's your intention to update the libraries normally provided by NuGet, you'll need to update the dependent projects' references to point to the project containing the updated code normally provided by the NuGet process.
Prior to checking-in your regular solution work (not the NuGet related libs,) make sure the solution's NuGet libs are up to date, and the references in the solution point back to the NuGet installed libs. Of course, you'll check-in and fetch the NuGet related libs beforehand.
I noticed yesterday that this error was happening in my local Windows Azure emulator when I debugged my web role. But the deployed project still worked on Azure. Today, my deployed project is failing with this same error. HELP PLEASE!
This code block in my Global.axax.cs file's Application_Start method:
GlobalConfiguration.Configuration.MessageHandlers
.Add(new BasicAuthMessageHandler()
{
PrincipalProvider = new PrincipalProvider()
});
throws this error:
Inheritance security rules violated by type: 'System.Net.Http.Formatting.JsonContractResolver'. Derived types must either match the security accessibility of the base type or be less accessible.
when I start debugging (this is an Azure web role project). But only sometimes (actually it seems to happen every OTHER time I debug) ... and all I have to do to fix it is to stop and re-start the debugger. What is causing the problem?
This had something to do with the Newtonsoft.Json assembly. I deleted it from my project's references, cleaned and rebuilt the project (for good measure), and then re-added it and rebuilt the project again. The error went away.
System.Net.Http.Formatting.JsonContractResolver is derived from Newtonsoft.Json. Another thread (here: http://forums.asp.net/t/1812274.aspx/3/10) addressed this same problem by removing Newtonsoft.Json from the GAC, since it was there and System.Net.Http.Formatting was not. This apparently solved a person's problem, although it seems backward to me (why can't the base type be in the GAC while the derived type is not? Isn't the error saying the problem is the other way around??).
Try updating your nuget packages. I updated mine, and it fixed the issue. I was also having this issue on azure service itself.