if you already checked aspnet_regiis.exe and it didn't fix your problem.
than come to
administrativetool >> ISS >> right click default web site.>> go for properties and choose home directory.
then click on configuration button. And manually configure the .aspx extension (using edit tab)and file path.
like : C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705\aspnet_isapi.dll
How do i create a dll [roject in c++.net using the managed classes. I can do this in the standard c++ but I dont know how to do this with the new .NET framework for c++. Any help in how to do this or simply set up the project would be great -- Thanks in advance
// I'm using Visual Studio C# and the 'EmailMessage' class. Here you see me attempting to retrieve data
// from: newDataSet1 (dataset), Settings (table), SmtpServer (data column) and convert ToString (strSmtpServer)!
// However what I have below retreives the DataColumn name and NOT the actual data (ie... smtp.yahoo.com).
// I feel I'm so close is scarry...
//Create the SMTP object using the constructor to specify the mail server
string strSmtpServer = (newDataSet1.Settings.SmtpServerColumn.ToString());
SMTP smtpObj = new SMTP (strSmtpServer);
Hello, i'm developing a .NET application which is linked with a native C++ library.
I'm using MC++ to be able to import DLL easily and to be able to manage the memory by my own.
I need to design several user controls (in an extern Dll then).
I don't know which language is the most suited to build custom controls as they provide the same access to the .NET framework.
I'v started building them in MC++ because i'm familiar with C++, i can import windows API easilly and some controls need loads of API calls.
Maybe designing custom controls should be done in C# because it's the dedicated .NET language.
C# may be more secure because each external API/struct will have to be specifically redeclared but is it worth it?
I'm excluding VB because i personnaly don't like the syntax.
Either C++ or C# are suitable. VC++ 7.0/7.1 are fullly capable in .NET. You get the best of both worlds using C++ because you have full access to Win32 without resorting to Interop as in C# Use the language you are most comfortable with.
deckards29 wrote: C# may be more secure because each external API/struct will have to be specifically redeclared but is it worth it?
It won't have to be redeclared. If you don't want something visible, make it internal or private.
If you're allowing COM interop so others can use the custom controls as ActiveX controls, you can also mark them with [ComVisible(false)] or declare them as above.
Here's how I see it, as somebody who uses Java and .NET every day:
1) Good to great integration with Windows, Active Directory, and other Microsoft products and services
2) Ease of integration with C++ code (in Java you must use JNI, not much fun)
3) The C# language is a little cleaner than Java and provides better support for OO development, with properties and a richer set of keywords. (A few things can actually subvert good OO design, like method hiding, but you don't have to use those features.) The language is more suitable for lower-level work than Java, while still providing all the features of garbage collection, multiple-platform deployment, etc.
4) The marketing muscle of Microsoft, nothing to sneeze at, means you'll be looking at green pastures for a while. Microsoft is also committed to supporting .NET for the foreseeable future, and has based much of their corporate strategy on it going forward.
5) The .NET runtime is better optimized for some things; object creation is less expensive in general, method-call overhead is a little less, etc.
6) The CodeDom namespace simplifies the task of dynamic code generation, something not supported in the Java core libraries
7) Excellent, excellent free documentation on everything you may want to do in .NET, with further support through the usually-excellent Microsoft Press books as well as authors of third-party publications (our own Nish and Tom Archer being a good case in point)
8) Ease of deployment for Web services is still far better than anything you'll see from a third-party Java tool IMHO, although I haven't seen the latest versions of Websphere Studio and BEA's tools
9) ASP.NET is better suited to RAD for presentation purposes. I'm sorry, JSP fans, but it's true; I know from experience.
10) Microsoft-centric developers are a little less likely to spend four hours a day at the water cooler engaging in object-oriented oneupsmanship.
All in all, it seems to me that they're about equal in terms of what's provided in their base libraries. Their security models are equally powerful and extensible, although with .NET you'll find it easier to work with Active Directory than othwerwise, no surprise there. Runtime speed of code is about the same in my experience, although I'd bet that calling native code on Windows works faster in .NET than in Java. They both have open specifications. They both have support for embedded code and small devices, with .NET support on the latter growing all the time.
1) Actual support for "write once, run anywhere". If you need to deploy on Linux or Unix, Java, C/C++, and/or something like Perl is still your best bet. Mono, the leading *nix implementation of the .NET framework, is still not as mature as the Microsoft implementation, and for reasons that'd require lengthy explanation, the two will probably never be fully compatible.
2) Better support for non-Microsoft technology. This is mostly just because of Java's longer history; while there are rabid .NET fans out there at this moment cooking up reams of open-source code to do just about anything imaginable, the jarheads have a head start. For instance, if you need to write an application to use multiple databases, just about every modern database vendor now provides a great type-4 JDBC driver, but support for .NET data providers is still not complete. (You can mitigate the effect of code branching by using a decent Data Access Layer in .NET.) Oracle and DB2 stored procedures can even be written easily in Java; both IBM and Oracle have invested heavily in the future of Java.
3) Lower cost of entry. I might make some people angry here, but you can still download Java for free and install it on your free Linux OS, and even run your applications on a free Java-based application server like JBoss, the same applications you developed on your free IDE. (.NET has free IDEs available also, such as SharpDevelop, which are great for the price but nothing near as good as Visual Studio .NET .) Total cost of ownership of a high-end site is debatable by wiser and more knowledgeable heads than I.
4) Better support for middleware, with the EJB standard. This is something that's currently lacking in .NET, although I'd guess that the plan is to sell extra "Yukon" licenses as middleware servers, since you'll be able to program stored procedures and other server-side objects in .NET-supported languages in that future version of SQL Server. (Of course, Jonathan Schwarz proclaimed the upcoming death of middleware in a recent issue of Java Developers' Journal. Also, Microsoft has chosen to go with a distributed-component model that is more services-oriented than Sun's; one can argue that this makes it less reliant on middleware from the start. Most applications don't need something like an EJB server anyway.)
5) A bigger developer community. This means you can get Java developers on the cheap, even easier than .NET coders. The .NET programming community seems to be more tightly knit, however, and is growing daily.
6) More access to the source and underpinnings of Java. In addition, there are many companies that provide Java Runtime Environment (JRE) implementations, in addition to Sun.
They're both viable platforms. A lot of it has to do with the specific situation. I have a lot of experience with Java, and I used to have a lot of animosity towards Microsoft as a company just because of the company I kept, but that's dwindling all the time and not something on which to base a purchasing decision. If you have a lot of Microsoft technology, .NET is the way to go, hands down. If you need to deploy mission-critical application on Unix, you have to go with C++ or Java.
I tend to think that Microsoft technology is better in general for small-to-medium-sized companies because it's very easy to learn, and productivity is easy to achieve. Like I said before, the RAD features of ASP.NET are currently unmatched; it seems to me that most of the in-house development needs for small-to-medium-sized companies are for database-driven Web applications, in particular reporting and intranet applications. Also, you won't get me to advocate buying into Java on this site, but I won't slam it either. You have to make your own decision!
Of course, you can always migrate your Java code to .NET; I have first-hand knowledge that the Microsoft-provided migration tools work well enough. On the other hand, it's not so easy to migrate .NET code to Java, but it can also be done, and you'll probably never need to do it.
Hi Jeff. Nice summary. We had a pretty low cost entry into .NET -- most of my first year's development with .NET came from the free .NET SDK download and a $30 text editor. It's not the funnest way to develop WinForm applications, but it was great for components and ASP.NET apps.
Thanks! I got started with my favorite editor and the command line, then started using SharpDevelop, then got VS .NET as part of our MSDN subscription at work, so I identify with you. I was perfectly happy working on the command line for a while; it meant that I didn't get bogged down learning how to use an unfamiliar IDE. I'm sort of a Luddite when it comes to this stuff-- I don't even use the .NET debugger, ever. I just use Console.WriteLine(), and haven't found a problem yet that I couldn't tackle with that! (I'm not knocking IDEs-- they get to be necessary just to manage files and class hierarchies as things get more complicated, of course.)
You can validate a license for design time and only provide designer support, etc. if your license exists. Otherwise you just perform only the run time services of the control.
Also take a look at the <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemcomponentmodellicfilelicenseproviderclasstopic.asp?frame=true" target="_blank">LicFileLicenseProvider</a> class.
We are currently investigating the use of SOAP as 'intermediate layer' between some complex modules.
.NET makes it very easy to create a 'Soap DLL' that is activated by IIS. Great.
However, we are considering to use this technology to access bigger server-style applications. These applications typically take several minutes to start up, handle a large amount of memory, and therefore cannot simply be recompiled into a kind of 'Soap DLL'.
Browsing through the Microsoft documentation I found an excellent AtlServer example that seems to do what I need. However, it would be much nicer if we could use the more modern .NET technology for this.
So here are the 'million-dollar'-questions:
- Is it possible, using .NET technology, to make a standalone .exe server-application behave like a SOAP-server via the HTTP protocol?
- Is it possible, using .NET technology, to make it accept SOAP requests via a message queue as well?
- If NO on the questions above, is using the AtlServer a step in the good direction or is ATL a dead-end?
- If YES on the questions above, where can I find good .NET examples on writing such a SOAP server?
Because I'm not sure in which forum to post it, I'll post it in 2 or 3 forums. Sorry if you get this multiple times.
Patje wrote: Is it possible, using .NET technology, to make a standalone .exe server-application behave like a SOAP-server via the HTTP protocol? Patje wrote: Is it possible, using .NET technology, to make it accept SOAP requests via a message queue as well?
So far I succeeded in writing:
- a C# stand-alone SOAP server
- a C++ stand-alone SOAP server
Next steps are to write:
- a .NET C++ class (or example class) that can be embedded in our applications to make it a simple SOAP server.
- a .NET C++ class to do the same for SOAP message queue requests.
Why C++? Well, the applications are all written in C++ and for the time being we like to keep our applications as 'compact' as possible. I mean, not a bunch of DLL's or components lying around, but a rock-solid executable file that simply needs to be copied on the system.
From what I understand from C#, the C# compiler cannot simply create an object file that can be linked with the rest of the application. With C++.NET this is still possible.
Have a look at gSOAP[^]. Its a clean, fast way to put a SOAP interface onto C/C++ programs. The server code generated is small and fast enough to be used in embedded systems, and has no nasty dependancies.
So, for gSOAP.
Is it possible, using .NET technology, to make a standalone .exe server-application behave like a SOAP-server via the HTTP protocol?
Yup, HTTPS too.
Is it possible, using .NET technology, to make it accept SOAP requests via a message queue as well?
Not directly using gSOAP, but you can create asymetric methods. You would need to create a proxy to get them to/from the SOAP service.
I looked at gSoap but because of its GPL license we cannot use it in commercial software. Although a commercial license for gSoap exists, I further looked into the .NET classes and since they are free (but tied to the Windows platform which isn't a problem for us) .NET looks the way to go.
So far I made a successful small .NET .exe SOAP server, and I'm looking further into embedding SOAP logic in our server applications that way.
Thanks anyway for your information.
Mark mentioned that I should use the XPathDocument rather than the XmlDocument in my code since I was not writing out XML.
Ordinarily I would agree but in this case I am loading an XML file into an XmlDocument and then re-using that same XmlDocument for another purpose. Would creating another XPathDocument to handle the second use of XmlDocument be better? ta
Christopher Duncan quoted: "...that would require my explaining Einstein's Fear of Relatives"