Migration OpenDJ to Directory Services 6.5 - directory

I'm currently use OpenDJ 2.6.4 in Suse Linux 11 and my goal is to upgraded to Directory Services 6.5.
From what I read, especialy on Chapter 9. Before You Upgrade
and Chapter 10. Upgrading a Directory Server, the process seems pretty simple, i.e, after checking Java version, backup and disable stuff we just need to execute the upgrade command.
This process run well or it's harder as it look?
From what I read on several release notes, i don't expect to have big changes on my current web application, is that right?

That is correct, there should be no change to the applications (since the interface is standard LDAPv3).
If your OpenDS service is replicated, you can upgrade one server after another, with zero downtime for the overall service.
When upgrading from 2.6, you will probably need to upgrade the Java runtime as well, since DS 6.5 requires Java 8 (and also supports 11).
So, stop a server, backup the whole server, unzip DS 6.5, upgrade Java to 8+, run upgrade, start-ds.
You might want to test the upgrade process on a dev environment. If you don’t have a dev env yet, you can create one by just copying the whole OpenDJ 2.6.4 directory and databases to a different location or another server.

Related

HOWTO: Visual Studio 2010 MVC3 Project on Win7 x64 Using Oracle ODP.NET 11.2

I have a new development machine Windows 7 x64 and am writing an MVC3 application that targets an Oracle database. I have tried everything that I know of to get it running with no success.
Previously, I was developing on a Win7 x32 box and could debug fine locally, but was unable to deploy and run it on a Win2008 x64 Server despite having ODP.Net and 11g Client installed.
"Could not load file or assembly 'Oracle.DataAccess' or one of its
dependencies. An attempt was made to load a program with an incorrect
format"
On my new x64 machine, I can build the project but when i try to run it in via the IDE I get:
"The provider is not compatible with the version of Oracle client"
I am at a complete loss.
Does anyone have a similar setup that could share detailed instructions of what to install where and how to to reference Oracle.DataAccess in such a way that I can debug in the IDE on my x64 box, and also deploy to x64 server?
It should not have to be this difficult.
I do have this running on Windows 7x64 with the Oracle 11g R2 client that comes with the ODAC installation here:
http://www.oracle.com/technetwork/topics/dotnet/index-085163.html
Make sure you have the x64 version installed locally, and you may have to do the uninstall-reboot-reinstall-reboot tango. I also had weird problems getting it to see TNSNAMES entries and had to go with EZCONNECT strings, but that's not your problem.
In fact, I've also gotten it working on x64 using the 32 bit EF beta and it works fine:
http://www.oracle.com/technetwork/topics/dotnet/downloads/oracleefbeta-302521.html
Although I don't think the EF implementatinon is 100% ready for prime time yet (we ended up using the DevArt driver instead because it had more reliable support for computed fields - we never did get Computed or Identity Timestamps working in ODP.NET EF Beta, although oddly Primary Key NUMBER fields populated by triggers did work.)
I didn't have to do anything special, and I didn't have to do anything special on the server side either (with both 10g and 11gR2).
So I finally figured it out. Here is what I did step-by-step:
On my Win7 x64 development machine I removed all Oracle products in an attempt to start from scratch (including manually deleting registry keys and files/folders)
I installed "Oracle Database 11g Release 2 Client (11.2.0.1.0) for Microsoft Windows (x64) " ON BOTH the dev machine and production IIS server
I selected the RUNTIME option for the installation
During my first attempt the installation complained of not enough room in the PATH
environment variable so I had to cancel the install, remove some path values (which a replaced after the install completed
I installed to C:\oracle was my base path and client_x64 was my HOME so it installed to C:\oracle\product\11.2.0\client_x64
I then installed "64-bit ODAC 11.2 Release 3 (11.2.0.2.1) for Windows x64" on BOTH the dev and production mahcines.
install.bat odp.net4 c:\oracle\odac11.2.x64 odac112x64
The above statement creates a new home named odac112x64
At this point I built a simple console app using the following setup
Added reference to Oracle.DataAccess.dll located in C:\oracle\odac11.2.x64\odp.net\bin\4
Set CopyLocal = FALSE for the Oracle.DataAccess reference
Set the application to build for "ANY PROCESSOR"
The app connected to my oracle database and returned records on both machines
I then created a sample MVC website project with the same connection code as the console app.
When I ran it locally in the IDE it threw an error:
"Could not load file or assembly 'Oracle.DataAccess,
Version=4.112.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342'
or one of its dependencies. The system cannot find the file specified."
I believe this is because the IDE is 32bit and could not load a 64bit Oracle.DataAccess
I published that exact code to the production server and it ran successfully
At this point my only problem is getting it to run locally for development purposes
I installed "ODAC 11.2 Release 3 (11.2.0.2.1) with Xcopy Deployment" which is the x32 version of ODP.NET
install.bat odp.net4 c:\oracle\odac11.2.x32 odac112x32
When I re-ran the MVC website project locally it worked as expected!
UPDATED FOLLOW-UP INFORMATION #1:
After getting this to work I attempted to apply the same steps to another server and it failed. The problem was that "Allow 32-bit Applications" was set to TRUE in the application pool. DISABLING 32-bit apps (only allowing 64bit) resolved the problem on the new machine.
UPDATED FOLLOW-UP INFORMATION #2:
The ODAC installation on the new machine failed to place the installation and bin directory in the environment path (I hate Oracle). Once that was added, all was running as desired.
I have not worked with ODP.NET for quite some time, so I am running from memory of issues I had when I last used it.
The ODP.NET bits have to be installed on the server (or at least deployed, although I am not sure how that is accomplished off hand). The actual client in ODP.NET is the same Java libraries used for Oracle access. If installed, then you have some type of configuration error or permissions issue with using the underlying Java libraries.
I am not sure what the IDE message is about, however.

Deploy from Visual Studio 2010 stopped working after upgrade to Web Deployment Tool 2.1

I have a web site project that has been existing for a while - it has been ASP.NET MVC2 based up until right now. .Net 4, Visual Studio 2010 Sp1, deployed to IIS 7.5 running on Win2008 R2.
I have four separate deployment profiles - "alpha", "test", "staging" and "live". Yes, I could probably have come up with better names, but they should hopefully convey what they are for.
It was recently decided to upgrade to MVC3 to take advantage of new awesomeness like Razor, global filter attributes, and start using NuGet etc. So I went on an upgrade binge with the Web Platform Installer. One of the things I updated was the Web Deployment Tool - both my developer machine (where the MVC3 upgrade happens) and the web server got this new version of the tool installed.
Since then, I have not been able to do deployments. I have gone back to earlier versions of my project (thanks to git for allowing me to painlessly go back to any previous version) and tried to deploy them, and they don't work either.
Whenever I try to do a deployment from Visual Studio I get the following error:
Web deployment task failed.((23.05.2011 11:18:24) An error occurred when the request was processed on the remote computer.)
(23.05.2011 11:18:24) An error occurred when the request was processed on the remote computer.
Unable to cast object of type 'Microsoft.Web.Deployment.DeploymentSyncOptions' to type 'Microsoft.Web.Deployment.DeploymentSyncOptions'.
I can see why that cast would be hard. ;)
But seriously - how can we get deployment from Visual Studio to work again? In the future we will do this using our CI server, and install a deployment package using MsBuild automatically on the correct web server depending on the git branch that was updated, but that is some time in the future.
I have full access to both machines so any other information need can hopefully be gathered.
You might be having beta version of web deploy on your box if you have ever installed web platform installer v2 beta. YOu can check that by
gacutil -l Microsoft.web.deployment.
If you see any 7.5.0.0 version then you have a beta version. Uninstall this version. You need to check and change this on both the client as well as the server.
Owais is right - this is very likely because you have a pre-release version installed. Rune can you please check and let me know?

Upgrading IIS web sever framework 2.0 to 3.5 considerations

i will be responcible for upgrading an IIS web server from the Microsoft .NET framework v2.0 to v3.5.
I am wondering if there is anything special i need to know or any caveats i should be aware of before proceding?
The site gets a fair number of hits per day and I will be taking it down and performing the upgrade at an off-peak time.
Aside from double clicking the installer is there anything i need to know?
Will the server need to be rebooted afterwards, does the installer handle all of the configuration changes? etc..
Thanks.
Upgrading from 2.0 to 3.5 is largely seamless since everything still hits the 2.0 runtime. I can't recall a single configuration change I made (aside from running the installer) to our production servers when we upgraded.
If you have a test environment I would really suggest running your upgrade there before your production to make sure you're not going to break anything. If that's not an option, I would recommend reviewing the Microsoft .NET Framework 3.5 Readme which contains some known installation issues and workarounds.

Do a Windows application ifself contain the .NET framework?

I have a Windows application which contain a deployer.
Does the deployer itself contain a copy of the .NET framework?
Or do we have to explicitily install it?
When I check in the solution explorer, it shows the .NET framework under the deployer project under detected dependencies?
My Windows application connects to the Internet to validate for a registered user. Do I need to configure some port (or something like that) while I am installing it? Also how do I check which port my application uses to connect to the Internet?
Regarding #1, just as Xstahef said, you need to prerequisite the .NET framework.
You could put the .NET redistributable in your installer, and if you detect that the .NET runtime is not installed then prompt the user to run and install the .NET distributable contained in your installer (that's what we did some time ago, InstallShield provided this functionality for us). But this may not be recommendable: the .NET runtime has grown a lot in size (depending of the version you need to have in your client's machine), and many customers (at least the educated customers) won't trust installing the runtime from your installer. Besides, you may need to check with the legal department in your company before including a third-party component in your installation.
It depends on your deploy project (Visual Studio, InstallShield?). But commonly, you need to force the .NET installation (prerequisite option). By default, .NET is not contained in the deployment projects.
Here, it depends on the way you want to connect the Internet.
.NET runs in a VM, so you would need to require the framework be installed in order to actually run it. Much like you need to have Flash or Java for those respective mediums. Microsoft has redistributable packages for the .NET framework. So you could probably incorporate them into your installer. If you're targeting 1.1 or 2.0 most people probably won't need it.
So long as you are not trying to get in to the client machine then you shouldn't need anything special like UPnP to [attempt to] open a port if they are behind a NAT router.
Xenocode does allow to running such an application on an absolutely clean PC.

Running a Data Synapse Win32 DLL Grid Node on a Windows 64 Machine?

We are developing a Data Synapse calc node process in C# that requires functionality in a Win32 DLL. We have no problems building this.
The question is it has to run on a Windows 64 bit system, with Data Synapse 5.1 Grid APIs for Windows 64. While Windows 64 will run most processes transparently using WOW we don't know that Data Synapse's 64 bit will in some way stop this from working?
Anyone done this?
8 Jun 2009: Update.
when we try to run a win32 service on the win64 grid we run into problems because on Win64 the grid code intrastructure runs as 64 bit Java. This java calls our service using a win64 JINI call to our service which is implemented as a DLL. Unfortunately as a Win32 DLL.
Do you want your C# code to run as a .NET service? .NET Services run in-process and as far as I know, there is no way of mixing 32bit and 64bit code within a single process.
I see two solutions
1) Run 32bit DataSynapse engines OR
2) Run the C# code in a surrogate 32bit process. Use some form of IPC to communicate between some stub code running in the engine process and the surrogate process.
I believe this infrastructure has already been built by DataSynapse for C/C++ code and is called IsolateService. To use IsolateService a simple C->.NET bridge would need to be developed on the remote end or a .NET executable wrapper developed to host the .NET dll and handle COMs.
Nathan
Maybe you can install and run a win32 engine at the win64 machine, in that case everything is in WOW.
If you try to install a win32 engine on a win64 machine, make sure that your installed manager is ALSO USING a 32 bits JDK Java (look for the environment variable JAVA_HOME).
So, in order to have a 32-bit running on a 64-bit machine, you must have a 32-bit Java JDK, and the DataSynapse manager must have been installed pointing to the 32-bit Java machine (when installing the manager, the JAVA_HOME variable should be pointing to the 32-bit version).

Resources