search

NETMF / netmf-interpreter

.NET Micro Framework Interpreter
http://netmf.github.io/netmf-interpreter/
Other
487 stars 223 forks source link

difference in build tools with regards to vs deploy #477

Closed SytechDesigns closed 8 years ago

SytechDesigns commented 8 years ago

This might seem a bit of an odd question. In mf4.3 if you had interop code in the build and you added the dlls to the DAT, then in a managed application, if there were NO references to the managed interop dll, then VS deploy treated deploy as if these items did not exist. In 4.3 qfe2 , the changes were all in the sdk, related to deployment and debugging and the VS vsix mechanism. I think the build tools changed as well, so if a project is built with later build tools - like mf4.4 - the build.dirproj, needs to have tools and bin in a directory above the main port directory, whereas in 4.3 qfe1, a build.dirproj, did not need these higher level directories. Is there a difference in the later debug/deploy mechanism, that now makes vs aware of all dlls in the DAT, regardless of if they are used, and require access to symbol files, pe files and dlls. We have a situation where interop code in a 4.3qfe1 port build, will work with vs2010 and will totally ignore 'unused' dat dlls, but built with later build tools, requires access to 'GAC' files, for the debugger to connect (even if the managed app has no reference to these dlls)- it deploys and code runs, but debugger will not connect. We get a dll 'might be optimised' error and other similar errors in the debugger. Its as if there is a new debugger mechanism - but the vsix can detect if the port was built with the old tools for backwards compatibility - so the same solution build behaves differently depending on the tools it was but with. If this question sounds a bit confusing and vague - its because, we have this strange deploy/debugging problem - but we are still investigating where the problem is coming from - and this is our latest avenue of investigation!

smaillet-ms commented 8 years ago

Yes, that does sound confusing/vague. ;-) Can you help me understand the problem with a simple set of steps to reproduce the problem? Visual Studio doesn't have any awareness of DAT files, though it can enumerate all assemblies found on the device. I'm not aware of any changes to the debugger behavior, though the debug experience shares functionality with VS itself so something may have changed there that we haven't seen yet.

SytechDesigns commented 8 years ago

Thanks Steve, basically I have a local version of mf4.3qfe1 , installed from the codeplex msi, we are also using a mf4.3 build set up on a Git Cloud, for joint development. The cloud repo has many additional features over the normal mf4.3 - but we are now in the position that the same solution built with 'plain' mf4.3 works just fine, but if built with our 'cloud' repo then we get problems with the vs (2010) debugger connecting, apps will deploy and run, just cant connect with the debugger. As you have confirmed that there are no significant changes in the underlying debugger mechanism, then we can eliminate this as a possible cause ( I know we were clutching at straws here!). Looks like whatever the problem is with our cloud repo - it is entirely all our own work!