Archive for February, 2012

Converting a Web Site Project to a Web Application Project

Differences between Web Site Projects (WSP) and Web Application Projects (WAP) are highlighted in blogs such as this one. Based on that, if you feel a WAP would be better for your particular needs than a WSP, but have already created a WSP, you may be asking yourself, “Can I convert my WSP into a WAP, without starting from scratch?”.

This posting explains how to convert an existing Web Site Project to a Web Application Project in Visual Studio 2010. The most striking differences to a Web Site Project are that WAPs have a project file to include and exclude files, and compile to a single assembly.

The guidelines below include several of the basic steps detailed in the Walkthrough: Converting a Web Site Project to a Web Application Project in Visual Studio. This is an excellent topic to review as it discusses some specific issues you may encounter which were discovered in previous versions of Visual Studio (VS). Please keep in mind while reading it that it is based on a WSP to WAP conversion using previous versions of Visual Studio.

Let’s get started.

Open and Verify your Visual Studio Web Site Project
Before converting your WSP to a WAP, you should open it in Visual Studio and verify that is it working correctly.  This will help prevent the need to research errors that have nothing to do with the conversion process.

  1. In the File menu, click Open Web Site.
  2. The Open Web Site dialog box is displayed.
  3. Select the project folder that you want to open, and then click Open.
  4. In the Build menu, click Build Web Site.
  5. In the Debug menu, click Start Debugging. Alternatively, you can press F5.
  6. Verify your project compiles and runs as expected

Create a new, empty Visual Studio WAP
A good strategy for converting a WSP to a WAP is to create a new, blank Visual Studio Web Application Project in a separate directory, but in the same solution. This avoids changing any part of the existing Web site files. It also allows you to copy existing functionality and files into the new WAP easily, within the same Visual Studio instance.

  1. In the File menu, click Add, and then click New Project.
  2. The Add New Project dialog box is displayed.
  3. In the Installed Templates section of the Add New Project dialog box, expand the language that you want to use, and then select Web to display the Web-related templates.
  4. Select Empty ASP.NET Web Application.
  5. Type values for NameLocation, and then click OK to create the Web Application Project.
  6. After the project has been created, delete the Web.config file that is created automatically.

WSPandWAP

Set Project / Assembly References
If the WSP required additional project or assembly references, you need to add them to the WAP. You can see the list of default references associated with the new (empty) Visual Studio Web Application Project under the References node in Solution Explorer.

  1. In the Solution Explorer, make sure Show All Files is turned on.
  2. In the Solution Explorer, right-click References, and then click Add Reference.
  3. The Add Reference dialog box is displayed.
  4. Select the reference that you have already added in the Web Site Project and then click OK.
  5. Note: To help prevent errors, add references to the Web Application Project for assemblies that existed in the \bin folder of the WSP.

AddRef

Copy and Convert the App_Code folder from the Web Site Project to the Web Application Project
In WSPs, the files in the App_Code folder are all compiled together and then referenced (automatically) as a “dll” by all other files in the WSP. In WAPs, this is not the case. All code is compiled together as one .dll. I’ve found that copying the App_Code folder over first and converting it to the WAP model helps to head off some dependency issues which could arise if one copied the entire site, converted, and then tried to compile.

  1. In the Solution Explorer, copy the entire App_Code folder from the WSP to the WAP
  2. In the Solution Explorerselect the WAP’s root node; right-click, select Convert to Web Application
  3. You will see our standard Convert to Web Application confirmation dialog.  Select “Yes” to this dialog.
  4. The App_Code folder should now be renamed to Old_App_Code folder
  5. Note: Do NOT name it back. As mentioned above, in the WAP model all code will be compiled into one assembly. At runtime, ASP.NET doesn’t know what type of project model you have created and will take anything in the “App_Code” folder and create a dynamic assembly for it, thereby causing “could not load type” exceptions as there would be duplicate types exists in two assemblies (the one for the VS web application and the one for App_Code).  Learn more about why App_Code folder does not work well with WAPs.
  6. Compile the WAP
  7. If you see an error, the most likely causes are:
    1. Missing assembly reference. See the section above to add missing references to your project.
    2. Files marked with Build Action = Content instead of Build Action = Compile. Any file you want compiled should be marked as such.
    3. To set the Build Action property:
      1. Select the file in the Solution Explorer
      2. Press F4 (Brings up the File’s Property Grid)
      3. Look at the Build Action property. Change as necessary.

converttowap

Copy and Convert the remaining Files and Folders from the WSP to the WAP
Once your Old_App_Code folder is compiled (by compiling your WAP in the step above), your WAP will have an assembly in the \bin directory. This will make it easier for the remaining files you are copying over to successfully compile, especially if they reference or use code in the files contained within that folder.

  1. Select the remaining files / folders from the WSP project and copy them into the WAP.
  2. Make sure not to copy the App_Code folder again.
  3. In the Solution Explorer, right click the root node of the WAP and select Convert to Web Application.
    1. Don’t worry, this won’t affect (or try to reconvert) any files or the Old_App_Code folder you have already converted.
  4. Note: This will cause VS to automatically generate a .designer.cs (or .vb) file for each page, user-control, and master page in the project. Additionally, each .aspx/.ascx will be modified to use the ‘Codebehind’ instead of the ‘CodeFile’ attribute in the Page directive.
    1. Example of the ‘CodeFile’ to ‘Codebehind’ change
      1. WSP file:  <%@ Page Title=”Home Page” Language=”C#” CodeFile=”Default.aspx.cs” Inherits=”_Default” %>
      2. Converted WAP file:  <%@ Page Title=”Home Page” Language=”C#” Inherits=”_Default” Codebehind=”Default.aspx.cs” %>

convertedfiles

Compile your WAP
After all the files have been added and converted, you should build your project again to see if there are any compilation errors. At this point, some of the most likely causes of errors are:

  1. Code files set with Build Action = Content. These should be changed to Compile. Refer to the above section.
  2. Missing project or assembly references. See above for steps for adding project or assembly references.
  3. Class name collisions. In the WSP model, each .aspx and associated codefile was compiled together as a separate, individual unit. Therefore, one could have files such as foo\widget.ascx.cs and bar\widget.ascx.cs where the classes were the same. Once these files are moved to a WAP and all compiled together, class name collisions occur with errors something like, “has multiple definitions with identical signatures”. If this occurs, unique class names should be created.

Run your WAP
After completing the above steps and you have a WAP which successfully compiles, you are ready to try running your application. One of the most common problems I’ve seen encountered is the “Unknown server tag ‘SomeTag: Control’ (as it applies to user controls and such)”. This can be corrected in one of two ways.

  1. Add or modify the register directive on the page that is using the control. This will only register it for this specific page.
    1. <%@ Register Namespace”namespace the control is in” TagPrefix=”SomeTag” Assembly=”Name of dll compiled into the \bin folder” %>
  2. Register the control in the Web.config, making it available to all pages in the project
    1. In the <pages><controls> section add the following:
    2. <add tagPrefix=”SomeTag” namespace=”namespace the control is in” assembly=” Name of dll compiled into the \bin folder” />


Hope this helps!

Advertisements

Convert “App_Code” to DLL

Question :

I have inherited a .NET 2.0 web project. It consists of a root site,
and 3 sub directories. Ideally these are seperate projects/websites. The root is a customer-
facing one, and the other 3 are for admin, and supervisor use. I want to break the existing project (all websites treated as one) into 4 separate websites. Unfortunately they all share the “App_code” directory, which contains
common classes to all 4 sites. Can anyone advise on how I can make the App_code a shared component in
4 websites, so that I can rebuild the entire app as 4 projects, which
will speed up development, and make it more robust (90% of development
and fixes go into the public site, why rebuild the other 3 every
time ?

Answer :

Create a new class library project (in the appropriate language) and copy
the App_Code files into that project. Run it until you can compile, as there
may be some web libs you need to reference, esp. if there is not a good
separation of concerns (likely considering you have library material in
App_Code).

After it compiles, take one of the websites and exclude everything in the
App_Code folder that you have moved. Make a reference to the new library.

Now go through and correct the using (C#) or Imports (vb) statements for
your project. Once you have a compile, consider it a test build and have
someone from QA (if you have QA) test that build thoroughly. Consider it
suspect, because someone may have tied in some config elements that are not
pulling properly into the lib, etc.

As it is being tested, go to another site and do the same. Rinse and repeat
until all sites are thoroughly clean and tested. Then, go back and delete
the excluded files.

NOTE: If you are using source control (you are, right), you can branch the
build before doing the switcheroo and delete instead of exclude at the first
step. It is unlikely you are going back. But, if you are, you still have the
old branch to go back to.

HTML5 (XHTML5) Validation Schema and Intellisense for Visual Studio 2008

I’ve been playing around with HTML5 (nice intro at Smashing Magazine) for a side project, and I wanted Visual Studio 2008 to stop telling me the new elements were not valid. So I created a new Validation Schema for Visual Studio 2008 that implements much of the HTML5 spec. I found some hints on how to do this in Visual Studio 2005 and went from there. Here’s a pic of it in action giving you the attributes of of the new <source> tag under a new <video> tag:

Readme.txt

  • There is a lot of confusion about HTML, XHTML, and mime-types. I’ve chose to go with a stricter XML-like syntax of closed tags and quoted attributes, rather than the looser HTML, so I called it “XHTML 5″ although that doesn’t really make it offically XHTML 5 until you do the rest of the research, work, and fun.
  • This is not a 100% perfect implementation. There are bound to be different interpretations of what’s “correct” HTML5 and you have until 2022 to get it right, so please don’t worry about it too much.

What’s Finished

  • All the new elements in HTML5 have been added in the follow groupings
    • structure: article, aside, footer, header, nav, section
    • media: audio, video, source
    • other: bb, canvas, command, datagrid, datalist, details, dialog, eventsource, figure, hgroup, keygen, mark, menu, meter, output, progress, time
  • When new elements have custom attributes (such as height and width for video, I’ve tried to add those)
  • I’ve also changed a few things like not requiring the type attribute on script blocks and allowing meta tags to have a charset attribute
  • I’ve begun adding HTML5 events (ondrag, onplay, etc.) but have not completed all of them
  • I am not sure how to add HTML5 style data- attributes, so those won’t validate yet.

How to Use it

  1. Download XHTML Validation Schema for Visual Studio 2008
  2. Save it to C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\schemas\html\
  3. Add the following to the Registry:

  4. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Packages\{1B437D20-F8FE-11D2-A6AE-00104BCC7269}\Schemas\Schema 23]
    “Friendly Name”=”XHTML 5″
    “URI”=”http://schemas.microsoft.com/intellisense/xhtml5
    “File”=”html\\xhtml5.xsd”
  5. Note that you might need to change “Schema 23″ to something else if you already have other non-default schemas installed. You just need to use the next available number in the list.

I hope you find it helpful. Please let me know if you end up using it and feel free to suggest updates or corrections.

HTML 5 intellisense and validation schema for Visual Studio 2008

You all probably know that new HTML 5 standard is coming. We made a new intellisense schema that you can add to VS 2008 or VWD Express 2008 and get intellisense and validation on HTML 5 elements. Note that schema is for markup only, we do not have DOM2 update for jscript intellisense yet.

How to install the schema:

  1. Download attached ZIP file.
  2. Place html_5.xsd in C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Packages\schemas\html
  3. Run either x86 or x64 reg file depending on the OS and VS/VWD flavors installed. For example, for VWD Express installed on 64-bit OS run HTML-5-Schema-Reg-x64-VWD.reg and for VS 2008 installed on 32-bit OS run HTML-5-Schema-Reg-x86.reg.
  4. Restart VS
  5. You can select HTML 5 in the schema dropdown and HTML 5 element attributes should appear in the Properties window.

On 32-bit OS path is C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\schemas\html. VWD shares folder with Visual Studio.

Schema is experimental and has certain limitations. For example, VS 2008 and VWD are not able to validate ‘wildcard’ attribute names, like HTML 5 data-* attributes and is not able to handle ‘transparent’ content model when element content is defined by the element parent (see, for example, A element). However, it may help you to start playing with the new standard.

Thanks

Download HTML5 Files

Calling Java Classes Directly from .NET

Calling Java Classes Directly from .NET

As the frequency of .NET and Java applications increases, we’re headed for an interoperability imperative—we have to get both sides to work together. One way to do that is by adding an interoperability layer that gives .NET direct access to Java classes.

t’s a fact that most production environments now use a mixture of both Java and .NET, despite all the partisan disputes over which side should “win.” To be prudently responsible in the face of this business reality, it is imperative that developers get both sides to work together. Interoperability is no longer an option: fortunately, you do have some options for choosing the best path for achieving interoperability for your project.

Your specific interoperability needs may vary, based on your current systems and project specifications. Perhaps you already have some perfectly good “legacy” Java code that you don’t need to change, but want to extend with new .NET components. Or, you’re creating a new system, and want to assign tasks to the better-suited platform, so you’re using J2EE’s Enterprise Java Beans (EJBs) for the scalable back-end system, and .NET Windows Forms to create a rich desktop GUI. In either case, you may need direct access to Java classes from .NET. This article briefly discusses the major interoperability methods available and highlights some issues to consider as you make your interoperability selection, and demonstrate class-level interop with a specific example.

Click here to see or hide the author’s description of other interoperability methods.

In addition, Web services use a SOAP-based communications mechanism that’s inherently slower than alternative binary communications mechanisms. Web services are also not well-suited for passing custom objects between Java and .NET as parameters and return values.

Visual J#

.NET supports development of systems using multiple languages concurrently. One way to support Java/.NET interoperability is to translate the Java code directly into .NET’s MSIL (Microsoft Intermediate Language) rather than into Java bytecodes. Although Microsoft can’t call its J# language Java, J# really is a way to compile Java code for .NET. Unfortunately, J# a significant limitation: it’s legally limited to the Java supported by JDK 1.1.4 plus JDK1.2’s collection classes. Using J# works only when these limitations don’t matter to you, and when you have access to the original Java source. However, when the Java code you need uses more advanced features, including just about any J2EE feature such as EJBs or servlets, or when you don’t have the source, J# isn’t a good choice.

Java Native Interface (JNI)

Java code can access, and be accessed by, non-Java code via the Java Native Interface (JNI). JNI is mainly suited for accessing Java code running in a standalone JVM on the same machine as your .NET code, and can be difficult to use. If you’re communicating with Java code on a different machine, or running in a J2EE application server, you may have problems. There are some third-party products that may help: JuggerNET, from CodeMesh ) is one example.

BytecodeTranslation

It may be possible to convert the compiled Java bytecodes to .NET MSIL so that you can link it directly into your .NET program. Microsoft’s J# distribution includes a tool called jbimp.exe that converts Java bytecodes to MSIL at compile time. Of course, jbimp.exe has many of the same limitations as J# in that it can convert only bytecodes from JDK 1.1.4 and earlier (plus JDK 1.2 collections. Unlike J#, however, jbimp.exe works without source code. IKVM.NET is an intriguing open-source project that translates Java bytecodes to MSIL as needed at runtime. In theory, IKVM.NET should allow any Java code to run on the .NET platform. However, the project is at a very early stage and far from complete, but certainly worth following for the future.
Close
Runtime Bridges

Perhaps the most natural interoperability method is to run the Java code in a JVM, the .NET code in a CLR, and use a runtime bridge to manage the communications between them. In this scenario, the .NET code calls .NET classes and objects that act as proxies for the Java classes and objects. The proxies manage the communication; the calling .NET classes aren’t even aware that they’re ultimately calling Java classes. A runtime bridge provides interoperability for a wide variety of architectures, because the Java code and the .NET code can be on different machines, the Java code can run in a standalone JVM or in a J2EE application server, and the solution provides interoperability for any JDK version. As with bytecode translation solutions, you need only the Java bytecodes, not the source.

There are several runtime bridges commercially available. The code for this article uses JNBridgePro from JNBridge. See the related resources section of this article for other bridge products.

In the remainder of this article, you’ll see how to use JNBridgePro to solve a real-world interoperability problem.

Build a Logging Example

Most software systems of any size or complexity contain a logging facility. Good logging packages exist for both Java (log4J) and .NET (log4N, which is the .NET equivalent of log4J). However, if a system contains both .NET and Java components, each side would be logged into its own logging package, which would generate two log files and make it difficult to collate or correlate the events logged. If you could instead use a single logging package to log to a single log file, you could easily see the sequence in which .NET-originated and Java-originated events took place. A single logging package also simplifies handling timing and file access conflicts among the multiple processes and threads attempting to log events.

You could choose either a .NET-based or Java-based logging package as the single logging package to be used from both .NET and Java. This example uses the Java-based package log4J to do the logging, but accesses the log from both sides, to demonstrate how transparently .NET can use existing Java classes.

The goal is to create a simple application containing both Java and .NET classes, where both the Java and .NET classes use the Java-based log4J logging package. The application has a .NET-based Windows Forms GUI, which calls the Java classes that perform the logging operations.

In the remainder of this article, you’ll walk through the process of setting up the interoperability project, creating the proxies, and building and running the project.

Requirements

To complete the project, you’ll need Microsoft Visual Studio .NET 2003 and the .NET Framework 1.1 installed on your machine. You can get the project to build using the .NET Framework SDK or Visual Studio .NET 2002, and .NET Framework 1.0, but you will need to make some modifications outside the scope of this article. The JNBridgePro documentation contains some suggestions on how you can proceed with older versions of .NET.

On the Java side, you must have a Java Development Kit (JDK) installed on your machine. You may use any JDK of version 1.2.2 or later. You can download a free JDK from Sun’s Java site.

Setting up

To set up the project, download the zip file containing the project code and unpack it. The zip file contains two sub-folders, Project and Completed. The Project folder contains all the code needed to create the project. The Completed folder contains the completed, ready-to-run, project, in case you don’t want to create the project yourself.

The Project folder contains dotNet and Java folders containing the .NET and Java portions of the project code, respectively. The Java folder contains a single Java class named JavaClass, which exposes a recordEvent() method that logs a supplied message to a specific logging category, as shown below:
package devX.logging; import org.apache.log4j.*; public class JavaClass { private static Category cat = Category.getInstance(“JavaClass”); public void recordEvent(String message) { cat.debug(message); } }

Although you’ll find the source file in the accompanying code, JavaClass is already compiled, so you need do nothing else to it.

In addition to Java code, the Project folder contains two .NET C# source code files. Form1.cs defines a Windows application that calls both .NET and Java objects, each of which logs events through the log4j Java-based logging package. The DotNetClass.cs file defines a .NET class similar to the JavaClass mentioned above. The DotNetClass also contains a recordEvent() method that logs a supplied message to a specific logging category:

 using System; using org.apache.log4j; namespace LogDemo { /// <summary> /// Sample .NET class that calls log4j. /// </summary> public class DotNetClass { private static Category cat = Category.getInstance("DotNetClass"); public DotNetClass() { } public void recordEvent(String message) { cat.debug(new java.lang.JavaString(message)) } } } 

Category is a .NET class that acts as a proxy for the corresponding Java Category class in the log4j package. .NET code accesses Java classes and objects by interacting with the corresponding proxy object. You’ll see more about proxies and how they’re generated and used in the remainder of this article.

The Completed folder contains everything in the Project folder plus additional files that allow the project to run without additional changes.

In addition to the project code, download the logging package log4j and unpack it in a location of your choice.

Finally, you’ll need JNBridgePro from the JNBridge Web site. For the purposes of this project, you may download either the EE or SE version. JNBridge provides 15 days of free use from the time that you install JNBridgePro; which should be sufficient to complete this project.

Install JNBridgePro by double-clicking on the downloaded installation file and following the instructions. Make sure that JNBridgePro is set up correctly by launching the JNBProxy proxy generation tool (through the Start menu or by double-clicking on the desktop icon). The first time you do this, you’ll see a dialog box that allows you to specify the Java configuration (see Figure 1). Make sure to check the “Start Java automatically” checkbox and specify a valid path is specified in the “Locate the java.exe file …” text box. After doing so, click the OK button. You can close JNBProxy at this point, or you can leave it open and proceed to the next step.

Figure 1. Specifying Java’s location: Use this dialog, displayed by the JNBProxy proxy generation tool, to specify that you want to start the Java side automatically and to specify the location of the java.exe file you want to use.

Generating Proxies
.NET classes communicate with Java classes through proxy classes. JNBridgePro generates a .NET proxy class for each Java class that you want to access from .NET. The .NET code then interacts with the proxy class, which manages the communication with the corresponding Java class. When you need an instance of a Java class, the .NET code automatically and transparently creates an instance of both the proxy and the corresponding Java object. To call a method on that Java object, you simply call the corresponding method on the proxy object. Similarly, to call a static method, you call the corresponding method on the proxy class, and to access a field in the Java object or class, you access the corresponding field on the proxy object or class.

The JNBProxy proxy generation tool creates these proxies and collects them in a .NET assembly, which appears as a DLL file that is linked into the .NET project.

To create the proxy assembly, launch the JNBProxy proxy generation tool (if it hasn’t already been launched in the previous section). Specify the locations of the Java class and jar files containing the classes for which proxies will be generated by selecting the Project, Edit Classpath… menu item, and then navigating to the Project\Java folder, which contains the devX.logging.JavaClass class file, and the file log4j-1.2.8.jar from the unpacked log4j zip file. Click on the OK button when you’re done.

Next, load the classes for which you wish to generate proxies into the proxy generation tool. First, select the Project, Add Classes from Classpath… menu item, and then type in the class name “devX.logging.JavaClass.” Make sure to check the “Include supporting classes” checkbox. Checking that option causes JNBProxy to generate proxies for all the classes that you might possibly need when accessing JavaClass. Click on the Add button, then on the OK button. JNBProxy will load approximately 200 classes. Repeat the process to load the logging classes in the log4j-1.2.8.jar file. JNBProxy will load a second set of classes.

You’ll want to generate proxies for all the classes you’ve loaded, so select the Edit, Check All in Environment menu item. Finally, select the Project, Build… menu item, navigate to the Project\DotNet folder, and enter the file name loggingProxies to generate a file named loggingProxies.dll containing the proxy classes. Figure 2 shows how the JNBProxy window looks after building the proxies. Note that you may get a warning message that some possibly required classes are missing. You can ignore this message, because these classes are necessary only if you want to log to other destinations, such as a JMS publisher—and you won’t be doing that in this project.

Figure 2. Generating Proxies: Here’s how the JNBProxy window looks after generating the proxy assembly.

Setting Up the .NET Program
Double-click on the Project\DotNet\LogDemo.sln file to open the .NET project. Before building the project, add the proxies to the project by adding a reference to the assembly loggingProxies.dll that you created in the preceding section. You also need a reference to the assembly jnbshare.dll that you’ll find in the JNBridgePro installation folder. Jnbshare.dll contains the core JNBridgePro functionality used to manage communications with the Java classes. After adding the references, you should be able to build the project without errors.

Figure 3. Starting the Binary Server: Here’s an example of the command line to start the Java side. Note that your paths may differ from the ones shown here.

To finish setting up the .NET program, copy the file jnbproxy.config from Project\DotNet into your build folder, which will either be bin\release or bin\debug, depending on your Visual Studio project build settings. jnbproxy.config contains configuration information that tells the .NET side where the Java code is located and which protocol will be used to communicate with it. In this case, jnbproxy.config specifies that the Java code is located on the same machine as the .NET code, that it will listen on port 8085, and will communicate with the binary protocol.

Running the Program

If you examine Form1.cs, you’ll see that it uses the BasicConfigurator class, which for demonstration purposes causes logged messages to appear in the Java console window. Note that it’s quite possible to log to files, JMS publishers, or other endpoints.

Before starting the .NET program, you’ll need to start the JVM containing the Java classes, so they’ll be able to receive the requests from the .NET side. Do this by opening a command-line window and typing in the following command line:

 java --cp <path to Project\Java>;<path to jnbcore.jar in JNBridgePro installation folder>;<path to log4j- 1.2.8.jar> com.jnbridge.jnbcore.JNBMain /props <path to jnbcore_tcp.properties in JNBridgePro installation folder> 

To be safe, surround each of the paths in the preceding command line with quotes, because they may contain spaces. The jnbcore.jar file contains the core JNBridgePro functionality that allows Java classes to communicate with the .NET side. The jnbcore_tcp.properties file contains configuration information that tells Java which communications protocol to use and which port to listen on for requests. The sample project uses the binary protocol and listens on port 8085. Figure 3 shows what you will see if all goes well.

Figure 4. The Logging Application: The figure shows the .NET front-end application that lets you log messages from either .NET or Java.

Next, start the .NET program from Visual Studio .NET, or simply by double-clicking on LogDemo.exe. Figure 4 shows the running application.

Clicking on the “Log .NET event” button causes the DotNetClass to log an event from .NET. Click on the “Log Java event” button to cause JavaClass to log an event from Java. You can either supply a custom message to log or just use the supplied defaults. In each case, the Java-based log4j package performs the logging operation, and displays the logged messages in the console window, as shown in Figure 5.

In this project you’ve seen how to log messages from both .NET and Java code into a common logging package—in this case running on the Java platform. Using a common logging package consolidates .NET-originated and Java-originated logging messages in the same console window or file, and lets you easily see the sequence of from both the .NET and Java sides.

Figure 5. Logged Messages in the Console: Here’s how the logged messages appear in the console window.

More generally, you’ve seen how call to Java classes directly from .NET by using a runtime bridge. In the sample application, .NET code calls Java classes in the log4j package, and also calls the Java class JavaClass. You can easily extend this technique of directly accessing Java classes from .NET to other Java class libraries, and you can also use it to let .NET classes access EJBs, JMS queues, or other Java and J2EE capabilities. Using a runtime bridge is simple, transparent, and extensible, because your .NET code accesses the Java code through proxies, and has no idea that it’s talking to Java classes.


Dotnet and Java

Java And Dot Net
This page I’m starting out of a real-world need, and this need is behind the name I chose, JavaAndDotNet, rather than JavaVsDotNet?. I’m actually a little surprised that no such page is already on wiki. Yes, there are bits and pieces. But I’ve had to do a lot of research in order to pull together the pieces. My need: to understand the features each platform provides– No, not features. I need to grasp the gestalt of each. I do not need to know which is better, nor do I care. Rather, I need to talk intelligently to my coworkers about how each approach applies to the design problems we face. Therefore, I’m interested in exploring both. –TimKing (DeleteWhenCooked)

JavaAndDotNetPhilosophies – Millieu

Java’s tagline has always been “Write once; run anywhere.” If .NET had a similar tagline, it might be “Write in any language; run on Windows.” Each adopts a different approach which permeates each community.

Java standards, for example, are specified and documented to be used in a variety of contexts and combinations. You can rearrange them ad hoc to devise almost any situation you desire. In contrast, .NET standards are designed for a given context and work well in that context.

Take JavaServlets, on the web tier. You can write them as pure Java classes. Or you can use JSP. You can use Struts or JSF or JSTL on top of JSP. Or you can shove JSP in favor of something like Tapestry. Or you can use these in combination in seemingly limitless ways. The resulting web application you can run on an embedded server like JettyServer. Or you can deploy it on a more elaborate server like ApacheTomcat (which could also be embedded) hosted under the built-in HTTP server Coyote, or under InternetInformationServer or ApacheHttpd (any of which Jetty could also do). Or you can go with a more integrated enterprise solution like JbossServer or IBM’s WebSphere or BEA’s WebLogic. Each possibility has its own strengths and weaknesses. It’s a stunning, confusing, and sometimes even frustrating array of alternatives and possibilities. And this is just looking at a single Java standard.

On the other hand, .NET WebServices use AspDotNet hosted under InternetInformationServer. Period. That’s it. No choices. No options. And nothing for you to screw up.

I think there are “not endorsed” way to do things via DotnetRemoting?, or even use a third party MiddleWare to achieve the same, however what you said is the MicrosoftWay.

This phenomenon manifests the difference between JavaAndDotNetPhilosophies. Neither is innately superior. The Java approach provides more choices and flexibility. The .NET approach provides more certainty and order.

(I used to think everyone preferred the former. As I’ve grown wiser, I’ve learned I was wrong. For an excellent example preferring the latter, see PageAnchor: generalization near the bottom of CsharpVsJava.)

There’s another important manifestation of this difference: How do you learn about each? With Java, you can go to the book store, where there are shelves of books from which to choose. But most Java technologies have good documentation available on-line. Some of Sun’s own Java books are even available for free download, but we still tend to buy paper copies of many of them. While Java books are very important to the Java developer, they fill a different role. We buy Java books after we’ve decided what we want to read. But they are not necessarily the first-chance documentation that .NET books are. In order to get started with .NET, you pretty much need to buy a book. You may need to buy that book even to understand exactly what .NET is and how to use it.

I’m going to disagree on that point. I got started in .NET by downloading VisualStudioExpress and using the tutorials provided with it. The MSDN documentation is usually very good (there are some notable weak spots) and is available online and as an additional 3.2GB install with VS. I needed a book to get started with Java web development because of the Java toolset’s looser coupling – while it gives you far more flexibility, it’s far harder to find a simple answer. It took me several days of shenanigans and broken Eclipse plugins to get an IDE working remotely close to Visual Studio in terms of web development. But I fully agree that if you don’t want to do it the Microsoft way, your choices become rapidly limited, as opposed to Java. — LiamClarke?

Maturity

(July 2005) Java is 10 years old. .NET is less than half that. When Java was only 5, it was a pain to work with. .NET is not quite the pain Java was at its age. However, .NET is still younger, and it shows.

Third-party support for .NET is weaker than for Java. In general, for any given design problem, many more Java solutions are available than .NET solutions. This is partially due to the Java approach (see Millieu on this page), but it’s also arguably due to the fact that .NET has had much less time to build a community.

Implementations

Though there are multiple sources implementing DotNet (MonoProject, DotGnu), the benchmark is MicrosoftDotNet. Other implementations are only partially compatible, and are likely to remain such, as the .NET core libraries are based on proprietary standards. (See DotNetForLinux.)

The core Java technologies, while their reference implementations are Sun’s, are based on open standards and have certified, working alternatives, including open source ones. There are multiple working implementations of both the standard runtime and J2EE (JbossServer, JonasServer?, WebLogic, WebSphere).

Languages

DotNet works with a number of programming languages (CsharpDotNet, ManagedCeePlusPlus, VisualBasicDotNet, VisualJaySharpDotNet). Note that porting standard CeePlusPlus or legacy VisualBasic to .NET can be harrowing. To do so, you must traverse a maze of exceptions, sacrifices, and compromizes designed to make these languages compatible with the CommonLanguageInfrastructure.

Some say CsharpLanguage is the “consensus” language for DotNet. Whether or not this is true, it is closest in style and features to JavaLanguage. In fact, C# and Java tend to leap-frog, pulling features from each other for each successive release. See CsharpVsJava.

Compilers do exist to turn languages other than JavaLanguage into JavaByteCode. But JavaLanguage is still the standard. If you want to design any heavy-duty software for the JavaVirtualMachine, you use JavaLanguage. Others are companion languages. (See for example JavaPython.)

Tiers and Technologies

InternetInformationServer hosts all WebServices in .NET. To design them, you can use AspDotNet (with MicrosoftWebForms), or you can use DotNetRemoting. The former is typically used on the web tier and the latter on the business tier. AdoDotNet can then be used to persist business data to any database that has a .NET DataProvider? or ODBC support. For example, you can use MySql using either of these: see http://dev.mysql.com/tech-resources/articles/dotnet/. Or you can use third-party tools to support ObjectRelationalMapping, or you can write your own database-access code.

In the Java world, WebServices can be hosted under almost any web server. On the web tier, JavaServlets run inside of a ServletContainer, frequently using JavaServerPages. On the business tier, EnterpriseJavaBeans (“EJBs”) run inside of an EjbContainer. EntityBeans (a type of EJB) can be used as a bridge to the database. ObjectRelationalMapping and JavaDatabaseConnectivity is also available. The companion and third-party technologies available to augment this simple scheme are too numerous to mention. Suffice it to say that none of these elements are set in stone.

Development Environment

Most Java developers use EclipseIde, NetBeans, or IntellijIdea. Most .NET developers use VisualStudioDotNet.

Java tends to support the latest development processes first. VisualStudioDotNet 2005 will add features, like source-code generation and automated refactoring, that have been available in the Java IDEs for years. JavaUnit is the benchmark for automated unit testing. Now, features like continuous testing (as continuous compilation before it) are being developed using Java.

How do tools used to design user-interfaces differ between the platforms?

Source Code

Sun publishes the source code for the core Java libraries. This can be valuable if the documentation is inadequate or if you need to figure out a bug in a library. I’ve saved countless hours debugging because I could step into the Java source.

For some projects, this may also pose a legal risk, requiring an explicit policy. For example, if you contribute to the Apache Harmony project, you may not contribute in any area in which you’ve “been exposed to” Sun’s source code, so that you don’t inadvertently violate someone else’s IP.

Java technologies also tend to have good open-source support. This is a side effect of the maturity and multi-implementation (“run anywhere”) approach.

Microsoft now makes the source code of the core libraries available for usage under their MicrosoftReferenceLicense?, and VisualStudio can be configured to retrieve it from Microsoft’s symbol servers as needed – but viewing the code carries the same risk for project contributors (most notably the MonoProject) as viewing Sun’s code.

BusinessValue aspects

DotNet is more “agile” (put it mildly).(say what?) Its characteristic lead some to wonder whether applications are developed to prove the concept (of DotNet), rather than to achieve a return for the business owner, who happen to require a SupplyChainManagement solution that rely on a particular WirelessDeviceEnterpriseComputing? implementation.

With JavaPlatform, the move is more “orderly” (put it mildly).(what?)Business owners are already redirected to the NextBigThing when an affordable Java solution comes out of the CommunityProcess?.

At this moment, owners of LegacySystems are wary of conversion to either platform, and BigBlue with its MiddleWare dominance is not complaining.

— PlainEnglishPlease

Client-side tool for ProgrammingOnHandHelds with MicrosoftWay constraints

Functionalities (including performance) that can be delivered using DotNetCompactFramework on WindowsMobile is very limited. Is there a better alternative using JavaMicroEdition, given the constraints where we are required to use WindowsMobile and DotNet servers? Or maybe someone have favorable experience on a toolset that is noncompliant with architecture of the above two StandardsStampingCompanies? (MS and Sun), yet can deliver superior results to staple solutions offered by the major software providers.

An acceptable tool will need hooks to client UI software such as a PocketWebBrowser, and can interface with addon package security solutions(e.g. kiosk mode “may be needed” in some usage scenarios). A reliable mechanism for persisting information “may be needed”, if WindowsMobile facilities cannot be used.

Poll : Which one is the Denno Secqtinstien Foundation Startup

%d bloggers like this: