from here, I want to download GDAL library. I mean I want to download .h, .lib, .dll files. I'm working in visual studio 2010 and using visual C++:
Solution Configurations : Debug
Solution Platforms : Win32
In fact I don't understand what's the difference between Developement and stable libraries?
And which one should I download?
Even I don't know what other information you need to post here?
The "stable" library is one that's been tested so they believe it to be reasonably bug-free.
The "development" library is one they're currently working on. It's probably had some new features added. It may also have had some bugs added, the documentation may be somewhat out of date, etc.
As to which to download: especially at first you typically want the stable version. It has a much better chance of working as documented (and, for that matter, of just plain working).
The development version is primarily for one of two situations: either when/if you think you might want to contribute some work to the library itself, or if it includes a new feature that happens to be really crucial to your work, so you're willing to put up with possible shortcomings elsewhere to get that addition.
Related
background
I have designed many tools in the past year or so that is designed to help me program for XPages. These tools include primarily helper java classes, extended logging (making use of OpenLogger and my own stuff), and a few other things that I personally feel I cannot work without. It has been discussed with my employer, and we feel that it might be a good idea to start publishing these items to openNTF. Since these tools are made up of about 3 .nsfs, all designed to use the same java code, key javascript classes, css, and even a custom control or two, I would like to consolidate key items into a plug-in that can be installed at the server and client level. I want to do this consolidation before I even think about publishing any of the work I've done so far. It would just be far too much work to maintain, not just for me, but for potential users. I have not really found any information on how to do such a thing in google searches. I also have to make sure that I am able to make use of the ExtLib libraries, openNTF Domino API, and the Notes API.
my questions
How does one best go about designing such plug-ins? Must a designer
use eclipse, or is this it possible to do this directly in the Notes
Designer?
How does a designer best go about keeping a server and client up to date while designing and updating the plug-in code? Is this why GitHub is often used?
Where is the best place to get material to get started in this direction? I sort of feel lost in the woods, knowing I need to head north, but not having a compass for that first step.
Thank you very much for your input.
In my experience, I found that diving into plug-in development is a huge PITA until you get used to it, but it's definitely worth it overall.
As for whether you can use Designer for plugin development: yes, but you will likely eventually want to not do so. I started out by using Designer for this sort of thing for a while, presumably with the same sentiment as you: why bother installing another instance of Eclipse when I'm already sitting in one all day? However, between Designer's age (it's roughly equivalent to, I think, Eclipse 3.4), oddities when it comes to working sets between the "Applications" and "Project Explorer" views, and, in my case, my desire to use a Mac app, I ended up switching.
There are two major starting points: the XSP Starter Kit (http://www.openntf.org/internal/home.nsf/project.xsp?name=XSP%20Starter%20Kit) and Niklas Heidloff's video on setting up Eclipse for XPages development (http://www.openntf.org/main.nsf/blog.xsp?permaLink=NHEF-8RVB5H). The latter mentions the XPages SDK (http://www.openntf.org/internal/home.nsf/project.xsp?name=XPages%20SDK%20for%20Eclipse%20RCP), which is also useful. In my setup, I found the video largely useful, but some aspects either difficult to find (IBM's downloads are shifting sands) or optional (debugging, which will depend on whether or not you're using Eclipse on Windows).
Those resources should generally get you set up. The main thing to worry about when setting up your Eclipse environment will be making sure your Plug-In Execution Environment is properly done. If you're following the SDK setup instructions, that SHOULD get you where you need to be.
The next thing to know about is the way plugins are structured. Each plugin you want to install in Designer or Domino will also be paired with a feature project (a feature can house several plugins), and potentially an update site - the last one is optional if you just want to import the features into an Update Site NSF. That's how I often do my normal plugin development: export the paired feature to a directory and then import the feature into the server's Update Site NSF and then install in Designer from there using Application -> Install. You can also set things up so that you deploy into the server's plugin/feature directories instead of taking the step of installing into an update site if you'd prefer. GitHub doesn't really come into play for this aspect - it's more about sharing/collaborating with your code and also having a remote storage location for your git repositories (which I highly advise).
And as for the "lost in the woods" feeling: yep, you'll have that for a good while. There are lots of moving parts and esoteric concepts to get a hold of all at once. If you mostly follow the above links and then start with some basics from the XSP Starter Kit (which is itself a plugin project that you can pair with a feature) - say, printing text in the Activator class and making an implicit global variable just to make sure it works - that should help get your feet wet.
It's best done in Eclipse. You can debug your code running on the server from there, as well as run it directly from there. The editors are also more up-to-date. You want:
Eclipse for RCP and RAP developers
XPages SDK for Eclipse RCP (from OpenNTF)
XPages Debug Plugin (from OpenNTF - basically allows you to load the plugins to the Domino server dynamically, rather than exporting to an Update Site all the time)
XSP Starter Kit on OpenNTF is a good starting point for a plugin. There are various references to the library id, which has to be unique for your plugin. Basically, references to org.openntf.xsp.starter need changing to whatever you want to call your plugin. You're also best advised to remove what you don't need. I tend to work in a copy of the Starter, remove stuff, build and if there are errors with required classes (Activator.java obviously will be required and some others), then paste them back in from the Starter.
XPages OpenLog Logger is a good cross-reference, that was built from XPages Starter Kit. It's pretty much stripped down and you'll be able to see what had to be changed. A lot of the elements of the XSP Starter Kit correspond to Java classes you'll probably be familiar with from your XPages Java development.
GitHub etc tend to be used as source control, which is useful for working out what's changed from time to time.
Our current system is in .Net world and we are in the process of moving to FeF world (Angular) and we might keep the back end either in .net or change it to some flavor of JVM. We do not know about the server side yet but for sure, we will keep it as .Net for some time till we sort out the technology issues.
One thing I want to do during this time to do is build a CI system with language agnostic build tools. We use NAnt/MSBuild today. I would like to know as of now what are all active build tools out there, which can work with any language? I did find the following, but not sure how many are all active today. I am not trying to find which is best or not, all I want to know is the tool set and I will evaluate them based on our project requirements. I want to make sure I did not miss some build tool because I do not know the Java world.
Current list
Make
Rake
Gradle
BuildR
I did find this question but it is 5 years old.
Thanks
Interestingly if you look at the visual studio files in a text editor you will see that they are indeed build scripts. They are actually msbuild.
Is there a way to make visual studio not care about dll versions? Is this a bad idea?
I am resetting up my dev machine and I just installed the latest version of Pex and Moles (version .92). All my projects are on version .91.
We are in the middle of a release and don't want to upgrade right now. Also, I cannot find an installer to version .91.
When I try to compile I get a message that I am missing the reference. (Hence this question)
The version is important.. By definition, there is a difference from each released version to the next (or there would be no need for a new version). Your program may not perform correctly if you are expecting one version and instead have another.
This was a part of what was known as "DLL Hell" in the pre-.NET days... If you needed to use a third party component (Crystal Reports Viewer is one we always had to deal with), you would just use the reference to whatever installed version was on the user's PC. Our retail locations had to have a specific version of Crystal Reports for their bookwork reports to print correctly, and because of that, we had to hold on to an old version forever.. Upgrading Crystal on the PC broke the vendor's bookwork app. On my first ever PC, I had several applications break when I would install or upgrade another. In particular, Real Player broke my telephone answering machine software. Goofy stuff like that...
So, the version IS important, even if it is an annoyance. It's also why I have a bias against third party tools that I have no code for, and can't recompile myself.
If you look at the properties of a referenced DLL, you will see a property "Specific Version". If you set it false, it doesn't track the specific version in the project file.
For this to work, you have to somehow fix the references where ever they are used. You can do this by opening every solution and fixing the references (at which time you could also just update the references to the correct version, paying heed to David's comments).
If you have a lot of solutions, you might use a tool like sed (see this post for windows versions of tool like this Is there any sed like utility for cmd.exe) to just update the project files as needed all at once.
In Visual Studio 2003, you could easily set your project assembly to auto-increment every time you built it, but with Visual Studio 2005, this functionality was removed. You can still auto-increment your assembly version on every build, but it's a complicated custom build step instead of an integrated feature.
I'm not sure why this was removed, but here's a question I should have asked a while ago - Should I be using a workaround to continue to auto-increment when I build, or is there a good reason to stop doing this, in favor of manually incrementing? Since Microsoft removed it from VS, perhaps there's a good reason, and I'm wondering if anybody knows it.
No, auto-increment on the [AssemblyVersion] is supported in VS2005 and up. Make it look like this:
[assembly: AssemblyVersion("2.0.*")]
I have little use for this capability myself. [AssemblyVersion] describes the outward visible public interface for an assembly. That doesn't change when I simply rebuild the assembly. [AssemblyFileVersion] is appropriate for tracking build numbers. Sadly, it does not have the auto-increment capability. Note how the .NET assemblies use that version numbering strategy as well.
Also note this feedback item.
I personally prefer not to do it since I at the moment work on a project where I need to be able to know exactly what features where added to exactly what version and if it autoincremented every time I built it would increase too rapidly.
However, I think it depends on your project if the advantages outweigh the disadvantages. Here's an old MS Patterns page that discusses advantages vs disadvantages of the built in auto incrementation:
http://msdn.microsoft.com/en-us/library/ee817676.aspx
I'm new to this so please make allowances.
I'm trying to build Audioslicer which seems to need a framework called IntervalSlider. The IntervalSlider build fails with:
framework not found InterfaceBuilderKit.
However, the framework seems to be present under the Frameworks group with the necessary headers.
Can anyone suggest what I'm doing wrong?
Thanks
Well, this looked interesting so I downloaded the source. I built it and got an entire slew of build errors.
It looks like
According to source forge, this project hasn't been update since 2006-12-04 and the default SDK is still set to 10.4.
This project uses a bunch of uncompiled libraries/frameworks which need to be compiled to work. Some of them may no longer compile now nearly 4 years later and on new hardware/OS.
This is a complex project which mixes, Objective-C, vanilla C and C++, so it's not the kind of project a novice can reasonably expect to get working. (I'm not even sure I could get it updated.)
In short, this looked like a good idea in its day but the project has gone silent, stale and out of date. You'll need to find an alternative unless you want to spend weeks or months (1) learning how to build such a complex project and (2) tracking down all the updated versions of libraries (assuming they exist.)
I advise looking for another solution. Too bad because this looked like a really neat idea. Such is the fate of a most FOSS. It takes too much drudgery coding to keep something like this up to date. All the fun in coding comes from the creation. Maintenance coding is about as fun as washing the dishes. Few are will to undertake such a chore year-in-year-out without pay.
In the future, always check the last project update date. If its more than a year or the before the last major OS rev, expect problems.