Right now you declare, and instantiate, CANMsgIdList in the 'Bar method:
List<MsgIdTimeStampMap> CANMsgIdList = new List<msgidtimestampmap>();</msgidtimestampmap>
So CANMsgIdList is a private variable that will never be accessible outside the scope of 'Bar.
You also declare, and instantiate, a variable with the same
name in the 'ReadLogFile method:
List<MsgIdTimeStampMap> CANMsgIdList = new List<MsgIdTimeStampMap>();
That variable will not be accessible outside the scope of 'ReadLogFile.
While the C# compiler will not throw an error if it finds variables of the same Types, and Names, in different lexical scopes (and ReSharper won't flag it either), having that kind of duplication is, imho, a recipe for confusing code, and future errors.
If you want to access the instance of CANMsgIdList in your Main procedure, or in other methods in your Application, declare, and instantiate, it once
in the scope of the Program/Class.
private void Bar()
CANMsgIdList = new List<msgidtimestampmap>();
files\log file with orange\logfile.asc");
If you go this route you can then modify the 'ReadLogFile method to return void:
private void ReadLogFile(string dataLogFile)
and eliminate the return statement in the method: now the instance 'Add method in 'ReadLogFile will operate directly on the instance of CANMsgList available to all methods in the Program/Class.
However, that's just one approach: there would be nothing wrong with passing the instance of 'CANMsgIdListas a parameter into 'ReadLogFile, and having 'ReadLogFile return the same instance
after it has been "fleshed-out."
The extent of "formality" in passing in structures as parameters, and returning them, is most often influenced by the extent you need to re-use methods.
It's a very good idea, imho, to define Type access modifiers as you create methods and fields, structs, etc. It makes your code much more readable, and helps highlight issues related to scope, like the issue here. 'public and 'private cost
you very little :)