Closed mattjphillips closed 11 years ago
Does your import library define a name in its ScriptAssembly attribute? That is what causes dependencies to be generated. You could remove the name... and I believe it should work. See the import library for the Script.Web.dll defining the DOM APIs ... that represents an example, where an assembly does not introduce a script dependency.
That did the trick! Thanks for the help.
I can't tell if what I'm seeing is a bug or just misguided application on my part. This is based on 0.8 using AMD loading.
I have an app which I'll call MainApp. It references an import library project for some JS library I'll call Foo. The import library project is called ImportFoo. The content isn't important, only that it's an import library, and MainApp uses it.
My HTML file is configured thusly:
Now, MainApp.js (built by S#) requires ImportFoo. This fails to load because ImportFoo.js doesn't exist; it's not a product of the import library project. Thus MainApp never starts up, because the require() never finishes.
I can work around this by creating my own stub ImportFoo.js file (consisting of nothing more than define("ImportFoo",...)), but it seems odd that I would need to do this; and furthermore that extra HTTP activity is wasteful. Perhaps I'm looking at all this the wrong way, but it seems like an import library reference shouldn't end up in the require() list -- it's implied that the JS is loaded manually, isn't it?
Is there a bug here, and if not, what's the correct practice for managing the import library references? It all seems kind of fundamental, so I have a feeling I'm just not understanding something about the import library workflow.