Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

DeploymentPath vs. Referenced Assembly #300

Closed
Mike-EEE opened this Issue Dec 18, 2012 · 6 comments

Comments

Projects
None yet
2 participants

Hello Community,

Just wondering what the thought process is behind DeploymentPath. It seems to me that I should be able to create a Script# class library and then add it as a reference to another dependent project, just like a typical .NET assembly. Then upon build, the .js file that's created from the Script class library is added to the dependent project (somewhere).

It would be valuable (and consistent) to have this functionality. IMO, of course. :)

Thank you,
Michael

Owner

nikhilk commented Dec 18, 2012

DeploymentPath is for some level of msbuild support for deploying generated scripts into web applications, and more generally copying scripts where project references don't apply/make sense (eg. web app project doesn't reference a script# project).

Where you can actually use project references, eg. one script# classlibrary referencing another, by default scripts from the referenced script# project are automatically copied (just like typical .net assemblies) ... the CopyReferences property on the msbuild task defaults to true.

Hope that clarifies. The functionality of references you're expecting exists, so I will close this out. If you feel there are other issues/suggestions, feel free to re-open or create another issue. Fyi, the code for this functionality is in https://github.com/nikhilk/scriptsharp/blob/cc/src/Core/Build/Tasks/ScriptCompilerTask.cs if you'd like to check it out.

@nikhilk nikhilk closed this Dec 18, 2012

Ah! That's great to hear. I am curious about why a web project referencing a Script# project doesn't make sense. In this case, I'm referring to the Todo Sample in the source Samples folder. It would seem to me that the web project would reference the Script# project just like any other class library, which in turn would place the generated script file from the Script# class library into a specified location within the Web Application... that is, that makes perfect sense to me. :)

Owner

nikhilk commented Dec 18, 2012

Currently those references don't make complete sense - you probably do not want the script# dll landing in your web app's bin directory ... partly because it uses a different mscorlib.dll and partly because its not supposed to be used at runtime.

As far as I know and have seen, putting the mscorlib.dll in the bin directory doesn't create issues, so lets assume for now, we're not trying to prevent that. However we also want to copy scripts over so they can be used at runtime, and the standard web project won't do so... since it only knows about .net assemblies.

Now all that said, there is hope based on some past prototyping. It however requires changes to system-level msbuild extensibility... so that we can introduce some msbuild logic into standard web projects to look for script# project references, and copy the resulting scripts as well. Extending those system-level msbuild is required because I don't want to introduce a custom web project in order to use script# (too intrusive of a change)... and that consequently would create the need to go back to msi-based distribution, i.e. away from vsix + nuget.

Hope that provides some background context on why/how DeploymentPath came to be...

If there are other ways to make the normal project to project references work for the web app project as well, then all ears. It would certainly simplify and remove the oddity that the special DeploymentPath property is.

I see what you're saying. Yes, that is a challenge, as the DLLs do get copied as well... didn't think of that. :)

I'm curious if a NuGet package installation might be able to modify all application projects within a solution to account for the behavior that you're describing. This might be something I can take a look at.

Owner

nikhilk commented Dec 18, 2012

Yes, on second thought it would be possible to build a nuget package that adds an imported targets reference to the web project... which looks up project references to find project references to script# projects and automatically pulls in scripts.

Would love to actually address this soon, so I can remove DeploymentPath along with all the other changes that have made their way into 0.8.

I would be honored to look into this. Although it might take me some time to get ramped on how to accomplish this with NuGet. If there is another NuGet package that does what we're aiming to do, I can check it out and take it from there.

Unless, of course, you were thinking of doing this and know exactly what to do. Then I'll just step out of the way. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment