Developing with .Net 2003
-
- KVRist
- 106 posts since 28 Apr, 2003
InstallShield...
-
- KVRian
- 1379 posts since 26 Apr, 2004 from UK
That's the past... Now Microsoft provides the installer directly.
-
- KVRist
- 63 posts since 31 Oct, 2002 from CA
well, I've tried all the options now (use MFC in static library, or use Standard Windows Libraries), and the plugin ALWAYS requires Msvcr71.dll to be installed on the system.
This wasn't the case in VC6, because it got statically linked with the project.
Is there any way to statically link this library .net? What are the options. Do I have to ship this dll also?
This wasn't the case in VC6, because it got statically linked with the project.
Is there any way to statically link this library .net? What are the options. Do I have to ship this dll also?
-
- KVRian
- 1379 posts since 26 Apr, 2004 from UK
Yes, you can link the lib statically.
Search in the linkage propetries, I don't remember the page as I don't have .NET on this computer, but it is a choice list with static single thread/static multithread/DLL single thread/DLL multithread or something like that. And the choice of your project is dynamic multithread(ed?) library, the fourth choice.
Nothing to do with MFC or something else. Just this list. - the page should be around the mean of all linkage properties and the list is around the bottom mean of the page -
Hope it'll help.
Search in the linkage propetries, I don't remember the page as I don't have .NET on this computer, but it is a choice list with static single thread/static multithread/DLL single thread/DLL multithread or something like that. And the choice of your project is dynamic multithread(ed?) library, the fourth choice.
Nothing to do with MFC or something else. Just this list. - the page should be around the mean of all linkage properties and the list is around the bottom mean of the page -
Hope it'll help.
-
- KVRist
- Topic Starter
- 46 posts since 20 Feb, 2003 from Scotland
In the end I ended up going the microsoft deployment route for the first public beta release. If I remember correctly this does package in MSVCP71.DLL into the deployment package. The end result, a 700K .dll is packaged into a 4.5 Meg zipped deployment file.
I'm sure there must be a better way, but for now I want to get on with the coding !
Andy C
I'm sure there must be a better way, but for now I want to get on with the coding !
Andy C
Music from the cut and paste generation
http://www.myspace.com/rtwoproject
http://www.myspace.com/rtwoproject
-
- KVRian
- 1379 posts since 26 Apr, 2004 from UK
But dinamically linked librairies are also slower than statically linked...
Perhaps bigger, but as you have to install the dll, it's approximately the same - with in my regards an advantage to static -
Perhaps bigger, but as you have to install the dll, it's approximately the same - with in my regards an advantage to static -
-
- KVRAF
- 4641 posts since 20 Feb, 2004 from Gothenburg, Sweden
You can use vs6 runtimes from vs7 (.net) instead of vs7, I don't remember how since I use vs6, but it's not that tricky. I would not settle for the deployment route if I could avoid it (which one can).
Stefan H Singer
Musician, coder and co-founder of We made you look Web agency
Musician, coder and co-founder of We made you look Web agency
-
- KVRian
- 1379 posts since 26 Apr, 2004 from UK
I thought the package was lighter... There are options to reduce the size in the properties pages.R2Project wrote:In the end I ended up going the microsoft deployment route for the first public beta release. If I remember correctly this does package in MSVCP71.DLL into the deployment package. The end result, a 700K .dll is packaged into a 4.5 Meg zipped deployment file.
I'm sure there must be a better way, but for now I want to get on with the coding !
Andy C
-
- KVRist
- 63 posts since 31 Oct, 2002 from CA
well, at this point, I'm actually thinking of going switching back to VC6, if I can't deploy my plugin without the msvcr71.dll otherwise.
The idea of linking the VC6 runtime libraries with VC7 sounds pretty good, I'll investigate into that.
Has anybody made any benchmark tests whether the VC7 compiler creates much faster code than VC6?
Peter
The idea of linking the VC6 runtime libraries with VC7 sounds pretty good, I'll investigate into that.
Has anybody made any benchmark tests whether the VC7 compiler creates much faster code than VC6?
Peter
-
- KVRian
- 1379 posts since 26 Apr, 2004 from UK
No benchmark, published benchmarks are not allowed by the .NET license...
I herad that the code could seem slower, BUT it can be because of the JIT at the start of the program, so after this step, the code is probably faster thanks to the optimization made during this compilation specially for your processor.
I think the code is faster, but it's only my personal analysis, don't take it for the real truth.
I herad that the code could seem slower, BUT it can be because of the JIT at the start of the program, so after this step, the code is probably faster thanks to the optimization made during this compilation specially for your processor.
I think the code is faster, but it's only my personal analysis, don't take it for the real truth.
-
- KVRian
- 539 posts since 27 Feb, 2001 from Vancouver / Canada
Guys, what is going on here? For plugins you don't need the NET framework, but you can use the compiler (as we at reFX do). Simply switch from dynamic linking to static linking and DON'T use any precompiled libraries (libs) apart from the system ones. If you want to use VSTGUI.lib, download the source and compile it yourself, also changing the settings to "static linking". The memory footprint is very low as only the functions used are linked, your plugin is then NOT dependend on ANY DLLs. Neither the old ones nor the new ones. Your plugin will grow in size but only by a few (less than 200) KILOBYTES.
Pete, your plugin already depends on DLLs, only the VC6 ones which are present on nearly every machine out there, you MUST to change your compiler-settings before shipping ANY commerical product, otherwise a LOT of users will not be able to use your product without download MEGABYTES of Microsoft packages etc. and you can bet that they will NOT bother just to use your product.
Pete, your plugin already depends on DLLs, only the VC6 ones which are present on nearly every machine out there, you MUST to change your compiler-settings before shipping ANY commerical product, otherwise a LOT of users will not be able to use your product without download MEGABYTES of Microsoft packages etc. and you can bet that they will NOT bother just to use your product.
-
- KVRian
- 1379 posts since 26 Apr, 2004 from UK
Well, I did'nt say that he must use the NET framework...
And with what you say, the dll that bothers him will still be there. Yes, if he uses VSTGUI, he has to recompile it, but the main thing is to get rid of this dll, and that's the case if he follows the instructions I provided.
And with what you say, the dll that bothers him will still be there. Yes, if he uses VSTGUI, he has to recompile it, but the main thing is to get rid of this dll, and that's the case if he follows the instructions I provided.
-
- KVRian
- 539 posts since 27 Feb, 2001 from Vancouver / Canada
The DLL will still be there? Yes, it will be on his hard-disc, because he installed the .NET compiler, but it will NOT be required by his plugin. I do ship *several* plugins, and NONE of them requires any DLLs.Miles1981 wrote:Well, I did'nt say that he must use the NET framework...
And with what you say, the dll that bothers him will still be there. Yes, if he uses VSTGUI, he has to recompile it, but the main thing is to get rid of this dll, and that's the case if he follows the instructions I provided.