|
adamUK wrote:
If you have got anything less than a 1 gig PC with 512 MB of ram then you might get frustrated.
Don't believe him!  I've got PIII 550 Mhz and 128 MB of RAM! VS.NET works on my PC really OK!
Or maybe I got frustrated and didn't notice that? 
Ñ There is only one MP Ð
|
|
|
|
|
adamUK wrote:
and takes up much (3.5 GB) more space on your hard drive.
Most of that space is used up by MSDN which, unlike VS6, is installed at the same time as the rest of the VS.
Looking at my full install, without the MSDN directory, it takes up 678MB.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
You simply forgot to mention all the "affiliate" folders such like :
- c:\program files\MS .Net
- c:\winnt\.Net
- c:\MSDE
- IIS (just to be able to run the quickstart tutorial)
- c:\winnt\system32\ all run-times
- + samples directory if you intend to learn something!
And I swallow a small raisin.
|
|
|
|
|
EBonizzoni wrote:
I'm interested in learning "standard" C++
Buy Visual C++ 6.0. I think it's really easy for beginners! I was learning C++ on Visual C++ 6.0.
Ñ There is only one MP Ð
|
|
|
|
|
If you are interested in "standard" C++ as you just said, then stay away from .Net : it is of full of proprietary attributes that turn programming into a knightmare. Many times you just lose the knowledge of what you are talking about. I have already been caught about 10 times with attributes that bind behaviors without being seen, and have seen myself as if I was a lousy VB programmer who doesn't know a sh*t about programming.
Since the MSDN doc is a reference, with no real tutorials about attributes and stuff like that, you'll end up being forced to buy a dozen books before you do anything reliable.
In some way, that's the next level after ATL, these f***ing undebuggable macros.
PS : on a 128MB RAM system, you'll be swapping all the time.
And I swallow a small raisin.
|
|
|
|
|
That's the future of programming! 
StephaneRodriguez wrote:
on a 128MB RAM system, you'll be swapping all the time.
As I said before, VS.NET works on 128 MB OK for me, but when my friend wanted to debug his app on my PC (to check his program on an old computer) it crashed. Why? He was clicking too fast! Maybe I'm just a slow programmer? 
Ñ There is only one MP Ð
|
|
|
|
|
No.
VS C++ 7 is next step for C++ compilers. That's more or less ok, even though I want to see perfs, benchmarks and reliable migration articles (ie non-marketing) about going from #6 to #7 : AFAIK, I already happen to live a knightmare between old and new ATL.
VS.Net including C#, aspx, ..., is VB programming-style, ie total lost of control. In addition, the API is too limited, many people are forced to use Interop (native win32, which is a slash over C#) for practically anything relevant.
Attribute programming (seen in almost all samples in the VSNet cd) completely sucks : it is full of proprietary MS things. Where is ANSI and so called standards ? Besides that, attributes makes debugging virtually impossible.
The future of programming ? Everything of this unreliable computing stuff we have seen for the last decade should be kicked to the trashcan, and we had better actually see us building a new, reliable, operating system based on transactions : an OS on which when you start a workflow that is expected to do something precise within 15 minutes, you come back 15 minutes later then either it's done, either you have all tools to rollback, resume, ... Complete user control. In other words, computers as simple tools, not as ends in themselves.
VS.Net is the total opposite : Complete MS control (many many many undocumented features and bindings), MS relying on developers for evangelization : that's the first time they go that far.
And I swallow a small raisin.
|
|
|
|
|
StephaneRodriguez wrote:
VS.Net including C#, aspx, ..., is VB programming-style, ie total lost of control. In addition, the API is too limited, many people are forced to use Interop (native win32, which is a slash over C#) for practically anything relevant.
I've been able to achieve a great deal without touching the Win32 API through interop, and when I do have to, I can pack it off into a legacy dll which can be replaced as the aging Win32 API falls off the face of the earth (cant wait...)
The .NET API is well designed and a GREAT first version. Win32 was a mishmash as a first version, and has only become moreso with time.
I agree that close to the metal is a good way to go for some things, and I do delve into the low-level programming when working on pocket pc apps, but I also want a rich, clean API with strong debugging and acceptable performance. C++/MFC/ATL/Win32 no longer takes that crown in my opinion.
As for complete MS control, C# is an ECMA standard, and if MS pulls the rug out from under the ECMA standard, its fairly easy to port C# code to Java (as long as you put your core logic in classes, a large project can be ported in a few days by search-replacing), so i dont think they would do such a thing. Their best interest is served by making C# more open than java.
perhaps you should investigate the .NET api, it sounds to me like you dont realize how coherent and open it really is... No offence ment, but it almost sounds like you got your opinion of it from a 'C# for C Zelots' article on slashdot.
|
|
|
|
|
Christopher Lord wrote:
I also want a rich, clean API with strong debugging and acceptable performance. C++/MFC/ATL/Win32 no longer takes that crown in my opinion.
With C# you no longer have a callstack beyond your own files. If you are a C++/MFC/ATL coder that's quite a shift, isn't it ?
If you accept this lost of control, that's fine. I don't.
Christopher Lord wrote:
As for complete MS control, C# is an ECMA standard,
A C# app is a WIN32 app with 100% proprietary stuff. I am not talking about it cross-platform, I am talking about it being documented. Only the surroundings are documented. The combination of interop/attributes/Net framework falls short of documentation, whereas that's exactly what we do in real apps.
Christopher Lord wrote:
Their best interest is served by making C# more open than java.
C# is nothing new, that's the rebranded MS JDK 3.0 (1997)
Get it!
Their interest is to take control of your apps by being the providers of an always changing run-time.
By 2004, a basic .Net framework run-time will be part of the OS, and your apps will force customers to buy new computers and hardware just to run it. That's the next level after MS forced us to buy new hardware just to run VS.Net. We developers have never been that much in the "buy-new-hardware" thing. That's what I see.
From my previous post, I have just realized you have skipped the "transaction" part. That's too bad, as it is my main feeling about .Net : great apps will say light of day, but the Object class implementation remains transaction-less, in other words the apps remain unreliable, just like win32 apps.
And I swallow a small raisin.
|
|
|
|
|
Using C++ with VS C++.net standard edition.
I can use the .net framework with my C++ application ?
is it what Managed C++ used for ?
I want to use the XmlWriter namespace ( if that's what's it's called ), is it possible ?
Sorry, if it's a really stupid question, but now, I'm really clueless ... I'm taking a couple of hours this afternoon to go buy a book about this ... any good suggestion ? mostly C++, Managed C++ .NET framework ...
Max
|
|
|
|
|
No! .NET Framework is not something like MFC.
You cannot use .NET framework in your C++ app.
Managed C++ is not the old C++, there are a lot of differences. .Net Apps work in other than normal Windows app.
Buy a book about .Net framework, what it is and how it works?
Ñ There is only one MP Ð
|
|
|
|
|
Maciej Pirog wrote:
You cannot use .NET framework in your C++ app.
Managed C++ is not the old C++
You *can* use the .NET framework in your C++ app; and Managed C++ is old C++ with some extensions to it.
Now there are some gotchas to be aware of; one is that an unmanaged class can't directly hold a reference to a managed pointer; the solution is to use the gcroot template class.
That said I recommend, Microsoft Visual C++ .NET Step by Step by Templeman and Olsen.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
James T. Johnson wrote:
Managed C++ is old C++ with some extensions to it.
And there are some C++ features that you cannot use in Managed C++. The main difference is not in language, but in the way it works! The C++ is compiled to the normal x86 code (in MS Windows), and Managed C++ is compiled to MSIL.
James T. Johnson wrote:
You *can* use the .NET framework in your C++ app;
Ok! Will you compile it with an ordinary C++ compiler or a Managed C++ compiler?
.Net Framework apps can use API or MFC functions and classes, but you cannot add things from .Net Framework to a normal app as other libraries.
Ñ There is only one MP Ð
|
|
|
|
|
I recommend, Microsoft Visual C++ .NET Step by Step by Templeman and Olsen.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
Does anyone know if there is an add-in somewhere that will do syntax highlighting for .IL files, or better yet, an add-in that extends VS to allow the creation of IL-based projects? Or if not, how I could write an add-in to do this?
Thanks
|
|
|
|
|
i am tring to develop an application which can install any type of software on any platform with out user interaction in dot net.
First of all my application will learn all events and messages at least one time then it will perform the task on the network on any computer.
is it possible?
if yes how?
can some one provide the helping metrial and links about that?
r00d0034@yahoo.com
|
|
|
|
|
when i use that function (AfxGetInstanceHandle())in managed class i got an exception i do not know how to handle it.
how to sue it in managed vc++ code ?
how to sue it in c# code ?
plz help me.
r00d0034@yahoo.com
|
|
|
|
|
- 21 MB for the default .Net framework (you have a link in CP homepage)
- 6MB for .Net SP2
- 6MB for MDAC2.7 if the application uses data access
- and depending on the application the user may be required to install IE6.0 (integration with windows forms, etc.).
And I swallow a small raisin.
|
|
|
|
|
Thanks. 
Mazy
"If I go crazy then will you still
Call me Superman
If I’m alive and well, will you be
There holding my hand
I’ll keep you by my side with
My superhuman might
Kryptonite"Kryptonite-3 Doors Down
|
|
|
|
|
I have a server that accepts a socket connections and accepts authentication requests in a specific protocol. I want to use this for an ASP.NET authentication. How can I make my ASP.NET app maintain a single connection to this auth server and send authentication requests to it?
I mean a COM object does not seem to be the right way anymore. What is the preferred .NET way of implementing this?
Thomas
modified 29-Aug-18 21:01pm.
|
|
|
|
|
I guess the "proper" .NET way of doing this is to write a class that takes the credentials and performs the authentication against the server. You create this object then once and store it in the Application context. But beware you better build this object with sound multithreading capabilities, otherwise this might become a severe performance bottleneck.
--Chris
|
|
|
|
|
So, what you suggest is that I create the class and initialize it on Application Start and clean it up when the Application quits (I am so new to .NET that I do not know the event names).
ok.. So this class would create multiple threads that maintain the session with my authentication server.
Sounds fine. Now I have to go about designing it.
Thank you
Thomas
modified 29-Aug-18 21:01pm.
|
|
|
|
|
Well with multithreaded I meant: I can handle multiple requests at the same time. Not that it creates multiple threads itself.
Think of 50 users hitting your page concurrently. It would be bad if all had to queue up to be authenticated one after another.
|
|
|
|
|
I was recently given an assignment which I thought would be very easy, but which is turning out not to be. Our application has a huge, MFC based, activeX control which runs in the browser. We want to use .NET to capture the bulk of this control's behavior on the server side.
However, part of the ActiveX control's behavior involves dragging and dropping icons on to images. We want to do this on the client side. (i.e., capture mousemove events for draging and dropping on the client side browser so that we are not making too many round trips to the server) In other words, we want the UI of the ActiveX control to work exactly as it does now in the browser, only with .NET tools.
Is this possible?
I can get the behavior I want by using .NET Windows forms controls. But Windows forms controls cannot be used in a browser. (At least I can't get them to). I can get some of the behavior useing .NET Web forms controls, but again, the interactivity with a web form control is limited because of the round trip nature of interacting between client and server.
I have come down to the opinion that the answer is to use a light weight ATL ActiveX control containing a web service proxy to communicate with the server. However, my supervisor insists that this is doable with a pure .NET solution. I can't find one.
Any ideas?
|
|
|
|
|
I'm having trouble with my MFC applications. Recently I've moved my projects from using the old Visual Studio 6.0 to Visual Studio .NET. I've also changed my operating system from Windows 2000 to Windows XP.
However, after I re-compiled and re-distributed my projects in Visual C++ .NET, I was informed by many of my clients that the applications will not open on their platforms (which they do not have Visual Studio installed). The errors being that there are several DLL files missing, including mfc70.dll and msvcr70.dll and a few others. I've tried to include those DLL files in the distribution packages, but that will increase the size of packages from less than 100K to over 1M. I've also tried to build my application using MFC in a static library instead of in a shared DLL. But that will still increase the size of my applications significantly.
But even with the above solutions, there are still problems. While my applications open on my clients' platform, some of the functionalities are loss (for example, the CFileDialog class doesn't work anymore).
This should be a common problem for many developers, I wonder if there's a better solution. Most of my clients are using Windows 2000 and Windows 98. Only a few of them are using Windows XP.
Thank you to anyone who can give me some advice.
J.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
