KVR Audio

PaintedBlue · Post by **PaintedBlue** » Mon May 10, 2004 8:05 am

InstallShield...

Miles1981 · Post by **Miles1981** » Mon May 10, 2004 8:38 am

That's the past... Now Microsoft provides the installer directly.

peteblues · Post by **peteblues** » Mon May 10, 2004 8:18 pm

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?

Miles1981 · Post by **Miles1981** » Tue May 11, 2004 7:41 am

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.

marcelus · Post by **marcelus** » Tue May 11, 2004 7:59 am

c++ stuff being developed with dyn runtime on .net 2003 also need MSVCP71.DLL

with the other ones you mentioned, you should be ok

marcelus · Post by **marcelus** » Tue May 11, 2004 8:01 am

do not link statically if you can avoid it

doing so will increase the loading time (and size) of your plugin

R2Project · Post by **R2Project** » Tue May 11, 2004 8:12 am

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

Miles1981 · Post by **Miles1981** » Tue May 11, 2004 8:13 am

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 -

stefancrs · Post by **stefancrs** » Tue May 11, 2004 8:26 am

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).

Miles1981 · Post by **Miles1981** » Tue May 11, 2004 8:34 am

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

I thought the package was lighter... There are options to reduce the size in the properties pages.

peteblues · Post by **peteblues** » Tue May 11, 2004 4:49 pm

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

Miles1981 · Post by **Miles1981** » Wed May 12, 2004 7:43 am

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.

Mike from reFX · Post by **Mike from reFX** » Wed May 12, 2004 8:15 am

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.

Miles1981 · Post by **Miles1981** » Wed May 12, 2004 8:24 am

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.

Mike from reFX · Post by **Mike from reFX** » Wed May 12, 2004 10:09 am

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.

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.

Developing with .Net 2003