Should mention I did this for all configurations, restarted the program a few times, sacrificed a chicken to Steve Ballmer...

Even someone more familiar with Windows development in general could perhaps indicate a few more search keywords I could try to pinpoint the issue? Resource file, rc, visual studio 2010 express, and the error message all seem to be pointing me back to the same solution I already tried.

Hi,

although I'm not familiar with win builds as well, I guess if I were you, I'd go through the following sequence:

1) Remove VS2010 and MaxSDK. 2) Install VS2010 and the MaxSDK. 3) Compile at least one example project from the SDK. 4) Duplicate the example project I successfully built, rename it according to my object and replace the code with my own. 5) Build the project. 6) If I got stuck at some point, at least I knew where my problem was. Depending on where I got stuck, report back here or on a VS forum.

Hope this helps, Ádám

Calmer heads prevail. Thanks Ádám. I'd gotten so focussed on the problem, kind of lost my zen.

I will start from scratch and see if the issue pops up again.

Ádám, thanks for your help but perhaps just one more question? I think I'm almost there but I'm stuck in .dll hell.

After a lot of revisions, it builds with no errors but when I run a patch with the object installed I get an error that the Max external cannot find a third-party dll libARvideo.dll

I've added the DLL to the project, added the associated libARvideo.lib file in Additional libraries (as I said it compiles with those libraries), but I can't figure out why the external complains about not finding the dll.

I've looked online and according to this: http://msdn.microsoft.com/en-us/library/9yd93633.aspx

So this sounds right. I've even double checked that I was doing this for both debug and release configurations.

Am I missing a step when adding it to Visual Studio? Is it a compiler step? I assumed it would be a lot like adding a framework on OSX, but I can't figure it out. :( Any suggestions would be greatly appreciated.

For now I'm able to sluff off the dll warnings by including the required dlls in the support folder. Now I can finally get on to actually debugging this thing.

If there is a more correct way I should be handling the dlls I'm anxious to know.

Hi,

AFAIK the whole point of using DLLs is that if you have a set of functions that is used by many programs (for instance, more than one external) then you can put that codebase in a separate DLL, so that you won't have to repeat the same functions in all your projects. Therefore you need to include the DLLs you are using in your distribution. If you don't want to use DLLs, you can always enable static linkage. It is also worth testing your results in another computer that doesn't have Visual Studio installed, to make sure you don't run into problems like the ones I had in this (still unanswered) thread:

Hope this helps, Ádám

Hi Adam,

Okay now that I've been through it myself that thread is exactly what I'm going through. It finally works but it was missing 3 Dlls including mscvp71.dll. Though I haven't yet done the release build yet so that's the only difference.

This is my first time developing for windows so this is all quite new to me.

Hi,

you shouldn't link against the MSVC*.DLL files, unless you really have a reason to do so, and specially not against msvcp71.dll. There is a custom build of Cycling '74 of these files, and you should link against those ones (BTW, if you create your external by modifying an already existing example project, this link would be set up by default). However, there seems to be a bug in the Cycling '74 solutions that will prevent this linkage if you use VS 2010 Express and C++/STL. In that case (at least for me) the easiest solution is to enable static linkage, which, although would increase the size of your external, makes sure that your deployment versions wouldn't depend on any MS library (which makes your life easier when looking for the proper license for your project).

Hope this helps, Ádám

P.S. I'm really wondering when the Cycling '74 developers will come up with a solution that works for VS 2010 without the need of redistributing the MS CRT (or the need of static linkage)...

I would just second the motion that static linking is more reliable for distribution of externals, even if it comes at the price of massive inflation of disk space.

Now that I mentioned 'the proper license', I just realised that static linkage of the MS CRT makes life, in fact, a bit more complicated. AFAIK one can only use VS Express for own purposes, but the redistribution of any MS DLL (or linking them statically to the project and redistribute the resulting binary) requires the full (paid) version of VS, specially if I wanted to sell my externals. This might be one of the reasons why Cycling '74 is distributing an own version of MS CRT. However, since this 'replacement' wouldn't work with VS 2010 (see my earlier referenced thread), that means that one either has to buy Visual Studio, or downgrade to VS 2008, or use some alternative build method (like Cygwin, which is no longer supported by Cycling '74). So now I'm a bit confused about the best linking method...

Sonofa... So all this time the reason I couldn't reference a project was a limitation of VS 2010 express... So... Much... Time... Wasted...

That explains everything. So what's the cheapest full version of MSVS2010 that'll allow me to link a static lib? $800?

Clearly the solution is to tell people to get a Mac.

Unless I can sluff a version of this open source project to the public that is bundled with the dlls I might have to wait until I can find someone to publish it for me. What a drag. :(

I guess you've misunderstood what I told... there's no limitation in VS2010, you can link statically whatever you want to. What I mentioned was just that there seems to be some incompatibility with the pre-set properties of the Cycling '74 example projects (they were created with VS2008) that, for some curious reason and only in some cases, will prevent VS2010 from linking dynamically the CRT version of Cycling '74 and instead, it would link your external against the original Microsoft DLLs. This is no trouble if you don't want to redistribute your project, but it might cause a headache to your future users as they'll have to install the VS2010 version of the MS CRT on their system to run your externals (at least some clients of mine reported that). If you link statically the MS CRT, however, everything will be fine, nobody would need to install anything else (and you can do so, actually this is how I'm developing my externals at the moment). What I mentioned was only, that I'm not 100% sure whether using VS Express, you are allowed to do so. But technically speaking, there's nothing that would prevent you from doing that...

Ohhh I understand.

Thank you so much for all of your patience, Ádám. You've been so helpful, I hate to feel like I've been pestering.

I guess I just need to figure out why I can't seem to force a static link to my 3rd party libs. Any suggested reading?

EDIT: I sort of answered my own question about the suggested reading so I thought I'd share:

This one article answers so many questions I thought I'd post it here for future use. Particularly the section on Custom CRT will be handy for people trying to understand the above conversation (remembering of course that there's one further complication with the MS runtimes needing to be consistent between any third party libs/dlls, ones own externals and the Max environment (assuming I've finally got my head around this).

For future reference, the static link issue as it turns out was this:

After setting up this project in VS2008 from scratch and making 300% sure that I was linking to the static libs correctly as it turns out the libs are only Import libs, not full libs so they reference the original dlls. Going through all of this did help me eliminate 2 of the 4 dlls it was complaining about (most importantly the ms runtime lib as well as the glut32 lib). So I tried, I think I'll just have to distribute as is... Dlls and all unless I can figure out how to rebuild the libs as stand alones instead of import libs. I think I have the required sources, but I think one of them might require the Microsoft Directshow SDK which is a royal pain to deal with.