Hallo I've failed to bind both versions of a LiteDB library to my project. There's a necessity to consume both versions to access old and new databases from GUI though.
Nothing, I've found on internet, functioned. The project took the newest one, 4.1.5.0 every time. Can You post the abrupts from .csproj and .config files which succeed?
I noticed that runtime version of both versions is identical. Can it be the cause?
Related
I've recently come to discover this ridiculous notion of protestware.
In my particular case it is related to the lastest version of the es5-ext package.
The recommendation i've received is to downgrade to version 0.10.53.
Unfortunately, this is opening up a whole can of worms - compile errors that seem to be related to versioning/dependencies.
Is there any way to remove the es5-ext package from a React web application?
From this thread it looks like this issue, alerts a lot of antiverios and scanner and the post install file will be removed at the next major relese
https://github.com/medikoo/es5-ext/issues/186
I started migrating my applications to PHP7 last year already using the PHP7 release candidate (7.0.0RC5) available at the time. I successfully made all required changes and the apps are all running fine on that version (PHP 7.0.0RC5).
Recently I started testing the code with the latest and greatest PHP-7 version (7.0.11) and everywhere in the code where 'require_once()' is used (not only my code but also in 3rd party libraries) the code breaks with " 'fileA.php'...failed to open stream: No such file or directory in...'fileB.php>' ".
I double-checked and compared all the php.ini settings between the two versions and I am certain there are no differences.
Question: Has anything changed between 7.0.0RC5 and now that causes the behavior of require_once to be different? Even just a pointer would be highly appreciated.
I am having difficulty getting a new version of a 3rd party SDK to import into Android Studio.
In the earlier version they released .jar and .so files which I copied into /lib and /jniLibs and then added the lib files into the Android Studio app and everything worked. The app ran, used the libraries and all was good in the world. Recently a new version of this SDK was released but in this new release they have resource files (but they are not compiled into the jar/so files; there is a $Rstring.class files that they say I should import. I've now spent days copying into various locations in the app project with no luck and the missing strings result in crashes when calling their SDK.
OK, I figure I'd try to import their SDK folder (which is how they document to do it if you are using Eclipse). Well, no matter what I've tried and after selecting the folder or SDK's project file I get a dialog asking for the Eclipse workspace and a list of what appears to be source file names. I can't get past this dialog because obviously I don't have their files.
Has anyone run into this and found a solution; perhaps I'm missing something in the process but after spending the better part of 3-4 days trying and searching and trying more things I'm hopeful for help from the community.
OK, I found the answer and it was a combination of issues in how this particular 3rd party distributed the SDK and not fully understanding the menu.
The 3rd party in question packaged the SDK with the output files of the build as well as files that needed to be imported making an import alone to not work.
Combine this with menu confusion: File->Import Module is NOT the same as New->Modules->Import Existing Project only added to the confusion.
The solution ended up being to use the File->Import Module which appears to be a very different operation and once done most of the issues where solved. It solved the main issues I asked above which was missing resourced.
Still missing was the library (.jar) files which had to me copied into the app's lib folder and "added as library" but the .SO files did not need to be copied and in fact doing that resulted in a duplicate files warning.
I'm not sure I can fully explain what happened but what I think happened is that the "module" was where the app read the .so and string resources from but was unable to load the .jar files because (I suspect) these files where not part of the module but rather where outputs of building the source and it was removing the source files which caused the inability of the new->Module->Import to fail.
Hopefully this makes sense or at least give someone an idea of what to look for when/if they run into a similar issue.
I'm using NuGet to create a 'web framework' package containing code, master pages, css, javascript, etc.
In an attempt to speed up the build / test process I'm running nuget.exe update packages.config but I've noticed that it behaves differently than the package manager console's Update-Package command.
nuget.exe update seems to leave the previous version of the package still installed, resulting in multiple versions of the package installed. This usually doesn't cause problems but the Package-Manager Get-Package command shows many versions installed and sometimes the project will fail to build.
Update-Package actually uninstalls the package then reinstalls it, this is cleaner but slower
My questions are:
1. Is there documentation about the difference / relationship between these commands
2. Is the nuget.exe update behavior of installing multiple versions a bug?
3. Is there a better method for creating a package in one project and updating it in another project in a fast & automated manner?
Unfortunately, there's not much official guidelines or documentation except from piecing together forum and work item threads.
Current package manager console behavior was first included as a result from discussion in this thread, which later derived in a work item (sorry, apparently not enough rep to post more links).
However, as others already noted, behavior is not consistent with nuget.exe, where there's no such switch.
So, in answer to your questions:
VS Package Manager Console and nuget.exe do have different behaviors and seem to be updated independently (which is very unfortunate).
nuget.exe update behavior of installing multiple versions side-by-side has been a design feature from the start, as you can find from a comment on David Ebbo's blog about NuGet command line (again, I would have given you the link, but SO still doesn't trust me).
Unfortunately I haven't found anything about using package manager console cmdlets during build. What you could try is manually deleting all folders with your packageId on a build event and then packaging and installing using nuget.exe. Essentially replicate what Update-Package does manually, since as David Ebbo says, the way you uninstall a package through the command line interface is by, well, deleting the folder (again, can't post a reference, this is a bit annoying...)
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.