KVR Audio

R2Project · Post by **R2Project** » Tue Mar 16, 2004 10:47 am

I've been writing a Vocoder DXi using .Net 2003 and am just about to release Beta 1 for testing. However the damn thing won't register on any machine that doesn't have .net 2003 installed. The documentation implies that MFC71.dll and MSVCR71.dll will be needed in the distribution.

So I'm trying to get the MS deployment tool working. It's still no go. Anyone any experience with this and like to give me a clue ?

Andy C

Ian F · Post by **Ian F** » Tue Mar 16, 2004 11:37 am

I believe that machines that want to use your app will have to have the .net framework installed. Its a Windows update download about 23meg.

R2Project · Post by **R2Project** » Tue Mar 16, 2004 11:44 am

I believe that machines that want to use your app will have to have the .net framework installed.

I don't think thats the case, the machine I'm trying to get this running on has .Net Framework 1.1 isntalled as far as I can see and installation is still no go !

Andy

GreazeBlade · Post by **GreazeBlade** » Tue Mar 16, 2004 12:06 pm

I'm not really sure, but I read something about writing a wrapper in C++ or alike around your dll to make it recognisable to your host.

R2Project · Post by **R2Project** » Tue Mar 16, 2004 12:09 pm

I'm not really sure, but I read something about writing a wrapper in C++ or alike around your dll

Hmm,
Perhaps I'm not making myself too clear. This is a C++ project that was created in VC++6.0 and then imported into .net2003 for development. It is creatign native .dll code and runs fine on the development machine inside Sonar etc. However it just won't register on any other machine !

Andy

Borealis73 · Post by **Borealis73** » Tue Mar 16, 2004 12:17 pm

Have you tried to create a deployment project in Visual Studio? Normally it takes all references to any COM and .NET dll's and adds those dll's to the deployment package. When installing from the created package, all COM dll's get registered automatically (that's my experience). .NET dll's do not need registration.

You can add all kinds of setup conditions to the deployment project. One that's automatically generated is the condition that looks for the .NET framework.

Good luck with it.

R2Project · Post by **R2Project** » Tue Mar 16, 2004 12:57 pm

Have you tried to create a deployment project in Visual Studio?

That seems to have done the trick. I've been playing with the deployment wizard all morning to no avail. It seems to be working now. I must have just had an option worng the first time I created the deployment.

Andy C

mike.0 · Post by **mike.0** » Tue Mar 16, 2004 1:05 pm

Doesnt it work when you just put MFC71.dll and MSVCR71.dll in the same dir as the .exe file?

R2Project · Post by **R2Project** » Tue Mar 16, 2004 1:35 pm

Doesnt it work when you just put MFC71.dll and MSVCR71.dll in the same dir as the .exe file?

It may do but I think the deployment route is safer as it takes care of the file locations and *hopefully* not over writing new versions etc.

Andy

exponent10 · Post by **exponent10** » Thu May 06, 2004 11:56 am

Hi
we have the same problem. Only way we found round it was to download msvcr71.dll from microsoft (do a search of their dll datatbase) and then on install stuff it in to
c:\windows\system32

That makes them work.
But if anyone has a more permanent solution we would love to hear about it

Peace
Exponent

Mike from reFX · Post by **Mike from reFX** » Thu May 06, 2004 12:03 pm

You have to change your project settings to staticly link the libs (.lib), not dynamicly (.dll). Then the libs are linked *into* your plugin and are not loaded later. If you use the compiled version of VSTGUI.lib, you can forget it. They have their settings to dynamic link. You need to download the source and compile it for yourself with static linking.

Cheers,
Mike

exponent10 · Post by **exponent10** » Thu May 06, 2004 12:21 pm

If you use the compiled version of VSTGUI.lib, you can forget it

That'll be our problem then. Downloading the source code now.

Thanks Mike

Peace
Exponent

wrench45us · Post by **wrench45us** » Thu May 06, 2004 2:07 pm

Microsoft changed the 'model' on all of us. Or maybe it was more like evolved.

At one time, the preferred developemnt model was dynamically linked dlls -- of so easy to update in the field, blah, blah, blah. Unfortunately this led to all sorts of unforeseen compatibility issues and version problem.
So then the model went to statically linked libraries -- you always know what you've got because you built it into the project. I believe that's still the way to go with unmanaged C++ projects.

With c# .NET, everything switched back to dlls and some kind of spooky magic project voodoo where the project figures out how to resolve the refernces. If it can't figure it out it asks you if you forgot to add a reference. The version world is all settled out by using their deployment project builder.
We had some .NET bells and whistles fresh kid do the first version of ours and I've been pulling things out of the deployment project ever since. Beware any custom actions, that's all I can say.

peteblues · Post by **peteblues** » Sat May 08, 2004 7:03 pm

Where can I set the option in .net to statically link the libraries? My only options are 'Use standard windows libraries' (which apparently links them dynamically), or use mfc libraries static or dynamic. Since I don't use mfc, that doesn't work for me either.
Any suggestions?

Peter

Miles1981 · Post by **Miles1981** » Mon May 10, 2004 7:53 am

Depends on the libs...
The libs must be compiled in static or dynamic mode.
Then in your project, you include them - in the linker, you add the .lib files -. Then .NET uses librairies for threading, and those are available as static or dynamic ones. So you have to choose. But everything is in the same property sub group of the project and everything should be in the help - and well more explained that what we could do

-

Developing with .Net 2003