Skip to content
This repository has been archived by the owner on Jun 5, 2019. It is now read-only.

InventoryHelper.FindObjectByGuid can't find libraries #429

Open
AlexandrSurkov opened this issue Mar 19, 2016 · 10 comments
Open

InventoryHelper.FindObjectByGuid can't find libraries #429

AlexandrSurkov opened this issue Mar 19, 2016 · 10 comments
Labels

Comments

@AlexandrSurkov
Copy link

Hello!

In 2010 I and Igor Kiselev made PKStudio - IDE for exploreing .NetMF porting kit.

Main features that it allows now are:

  • View Solution as Tree;
  • Edit source files;
  • Compile projects from IDE without any console manipulations;
  • Jump from compile errors to their possitions in source file editor;
  • View Libraries, Library Categories, Features, Processors, Assemblies as Trees;
  • View it's properties in Property Grid and in Forms;
  • Search Libraries, Library Categories and Features by Name;
  • Verify components references and GUIDs;
  • View realtionships between components in graphic diagrams;
  • Convert MFProjects to fully compiling and linking Keil uVision project

I move it to GitHub and now trying to update it to support .NetMF 4.4 repo.

I found that code into netmf-interpreter\CLR\Tools\PlatformDesigner\ComponentObjectModel\InventoryHelper.cs in line 188 leeds that FindObjectByGuid method can't find any librar:

 private object FindObjectByGuid(string guid, IList list)
        {
            string key = guid.ToLower();
            if (m_guidToObjectHash.ContainsKey(key))
            {
                object o = m_guidToObjectHash[key];

                if (!list.Contains(o))
                {
                    Console.WriteLine("Warning the list does not contain a global libary");
                }

                return o;
            }

            if (!(list is List<Library>))
            {
                foreach (object o in list)
                {
                    try
                    {
                        string g = (o.GetType().GetProperty("Guid").GetValue(o, null) as string).ToLower();

                        if (0 == string.Compare(g, key, true))
                        {
                            m_guidToObjectHash[key] = o;
                            return o;
                        }
                    }
                    catch
                    {
                    }
                }
            }

            return null;
        }

InventoryHelper.cs was changed in 4.2 comm brunch. But changes was not moved to dev.

So can InventoryHelper.cs be changed like in in 4.2 comm brunch?

@smaillet-ms
Copy link
Member

Feel free to make the change and submit a pull request.
Fair warning though:
The whole FeatureProj, libcatproj etc.. mechanism is a headed for the scrap heap. It was a valiant attempt to solve a complex problem of dependencies , but in the end proved more complex and confusing than helpful. Some of it's design was driven by the fact that we didn't have vcxproj files so native code project references had to be handled completely custom (so in part it was also solving that issue as well) We now have VCXproj files, NUGET packages and CMSIS-PACK. In combination, those all solve the problems the featureProj and related support was trying to deal with. Rather than forcing the re-creation of project dependency data from one of the existing modern forms, NETMF should shift to just leveraging the existing forms.

I've started creating some code to download, unpack and read description files for CMSIS-PACK already. For, VCXPROJ, ideally we want to have a tool to auto convert from the current for into a proper VCXPROJ. (IIRC, PKStudio had something of this nature for conversion to uVision projects so this may be a great area to leverage some of PKStudio). We'd need to manually convert a few projects to make sure we understood what needed to be done but converting the majority of existing projects should be fully automatable)

@AlexandrSurkov
Copy link
Author

@smaillet-ms Thanks for answer!
You right, PKStudio have mVision converter, but it use different technique. It compiles project and then it parses log strings with call of armcc, armlik and other tools to get all arguments and file lists for each tool call.
And when it get all these information it can create uVBision project file.

We try to get these arguments and file lists from .proj files, but it is very difficult even with Platform designer libraries.

So, I think it is not the best way to create vcxproj files. But I can try to find some way to create new converter tool.

First of all, I need to understand VCSPROJ format. I found article about vcxproj files. If you have something else about it, please give me links.

@smaillet-ms
Copy link
Member

For the most part, You wouldn't need to worry about individual command arguments, that would be covered by a toolset specific set of property sheets and targets

@AlexandrSurkov
Copy link
Author

Do I understand correctly that if we create right VCSPROJ files then solutions will can be compiled with Visual Studio ?

@smaillet-ms
Copy link
Member

Not exactly, no. There are multiple pieces involved. The .VCXPROJ file is what matters the most for an auto conversion. But, by design, the bulk of the content in a VCXPROJ file is declarative, e.g. The type of project, (static lib, dll or exe) the actual source files, etc... Most of that data is available in the current dotnetmf.proj files for C++ libraries in NETMF so it becomes translation for that part. For x86+Windows, that's all you'd need (since VS ships with support for that OS and the MS compiler toolset. ) for additional targets/compilers we'd need to extend the Common Project System to handle additional tool chains. Though there is already some work on that front in the multi-platform targeting of VS plus work done in some other projects.

@smaillet-ms
Copy link
Member

Once we get the basics of building library code, we can add support for generating the final binary images, hex files compressed NMF files etc... small steps first though...

@cw2
Copy link
Contributor

cw2 commented Mar 28, 2016

@smaillet-ms Would you consider starting a separate discussion to summarize what is currently being worked on and to gather some ideas regarding build system overhaul?

Personally, I would be very interested in extending the CPS to handle additional toolchains - I have checked VSProjectSystem project on github and it seems to be somewhat lacking in the most important area (page Extend an existing project type is empty, despite the issue #73, which is now several months old). But, I am not sure whether the NETMF build system needs to modify the existing Visual C++ projects (to handle additional toolchains) or to create a new project type that would support various toolchains from the beginning.

@AlexandrSurkov
Copy link
Author

I agree with @cw2 . This issue not so good place to have discussion about CPS.

@smaillet-ms Sorry, but I still can't understand benefits of using VCXPROJ if it can't give chance to use Visual Studio for automate configuring and building processes.

The idea of separate code for logical parts (features, library categories and libraries ) is not so bad in my opinion. Problem is in the some kind of chaos in these parts and links between them.

It is very difficult to understand how to start work with netmf. For example, I have device based on LPC1768 that collcects data from other devices by CAN and translates it to server by Ehernet. And now I think that benefits of .net and C# are less than problems from creating new port of netmf for my device. Even considering the fact that I already know what's inside netmf and what I need to do.

But what about peoples who try to use it in the first time?

PKStudio was attempt to simplify work with netmf repository. And I still think how to continue this work. Many people in Russia ask russians Microsoft evangelists about NetMF. I wrote some articles (Russian versions here) to help them with start of using netmf. But this is just samples.

The task of create new port for custom hardware board is still very difficult. And I want to support netmf by simplify it use cases. I can create converter but I can't understand why VCXPROJ and what exactly needed to do.

There are Windws (Native Windows Solution) and Windows2 (Emulator solution). As first step, both solutions can be compiled by Visual Studion with right VCXPROJ files?

@smaillet-ms
Copy link
Member

There are actually multiple things going on here that come into play, only one of which is being able to actually compile source code into libraries and executables. A separate but related piece is where I think you are concerned is in resolving dependencies, particularly the soft dependencies. Where soft dependencies don't have a specific project or lib requirement but rather have a dependency on at least one implementation of a particular set of APIs being available but it doesn't matter which particular one. Thus someone must make a decision when multiple possibilities exist and there's no way an automated system can filter out on-applicable options. These are related but distinct issues and we shouldn't presume to co-mingle them.

I'll try and write up my thoughts on all of this starting with a definition of the various problems and how they interrelate, then how we currently deal with them (or don't as the case maybe) finally covering what I think will be the ideal modern solution we should drive towards.

@smaillet-ms
Copy link
Member

I've started the explanations with a general description of the build system requirements and definitions of the problems it is trying to solve here: https://github.com/NETMF/netmf-interpreter/wiki/BuildSystemRequirements I'll add another focusing on the ideas for a future re-worked system for the build, there will likely need to be a few such topics to really cover it all. As usual discussions and feedback are welcome. Nothing is committed in stone at this point. It's mostly just been flying around in my head for a while now.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants