|
Hi,everyone!I have a XML, its structure was like below:
<Height>
<Standard>4721
<PN>1.6
<A DN="250">300</A>
<A DN="350">400</A>
<A DN="450">500</A>
<A DN="550">600</A>
</PN>
<PN>2.5
<A DN="250">300</A>
<A DN="350">400</A>
<A DN="450">500</A>
<A DN="550">600</A>
</PN>
</Standard>
</Height>
I want to get the selected node's text,for example,when PN = 1.6,DN = 250,the selected node's text was 300;PN=2.5,DN=350,the text should be 400.I tried use "for each node in childnodes",but it returned "1.6 300400500600".How could get the node I wanted?
I think that should be first selected "PN",and then get each childnode in <pn>. But I don't know how to do this 
PLZ give me some help,thx!
|
|
|
|
|
System.Xml has a method SelectSingleNode, which requires an xPath expression in order to work. Your method should look somewhat like the following:
Sub GetSelected(string _PN, string_ DN)
' Put some code here to read your XML document into a XMLDocument variable,
' called XDoc for instance.
XmlNode _XN = XDoc.SelectSingleNode("/Height/Standard/" + _PN + "/A")
End Sub
(yes, I'm not a hero in vb, 5 pts if you guess my 'dialect').
Hope this steers you in the right direction!
"My personality is not represented by my hometown."
|
|
|
|
|
Hello,Eaverae! Your suggestion is helpful for me to get more details about the method "SelectedSingleNode".Thank you! I have got my solution like below:
For Each node1 In list1
Dim val As String
val = node1.Attributes("PN").Value
If val = TextBox1.Text Then
Dim list2 As XmlNodeList = node1.SelectNodes("Height")
Dim node2 As XmlNode
For Each node2 In list2
Dim val2 As String
val2 = node2.Attributes("DN").Value
If val2 = TextBox2.Text Then
TextBox3.Text = node2.InnerText
End If
Next
End If
Next
What's more, I have change the XML element
<PN>
to
<PN PN="1.6"> 
|
|
|
|
|
I am learning to program in VB.NET(2008 Express) and also learning to use version control software (TortiseSVN).
I am creating simple projects with VS while I learn the language(Using the book VB 2008 Step by Step ).
I have not been able to determine if I should put all the files in the project directroy under version control and if not what files and folders to exclude.
I am not sure what the files in the project directory do, any infomation would really be helpful.
eg of contents of project folder.
bin (folder)
My Project (folder)
obj (folder)
*.vb
*.resx
*.vb
*.sln
*.suo
*vbproj
*.vbproj.user
Thanks cages
|
|
|
|
|
There is no need to keep the bin folder and its contents in source control. Same applies to the suo and vbproj.user files.
SUO files contain information about IDE settings for the user while .user contain similar information for the corresponding vbproj.
|
|
|
|
|
I will try working on a simple project not including the:
obj and bin folders
.suo and .vbproj.user files
I can't use VisualSVN as I am working with the Express version of VS. Does any one know what files VisualSVN puts under source control?
Is there a document that explains the project structure for VB.NET?
Thanks,
cages
|
|
|
|
|
I'm not familiar with TortiseSVN; my shop still uses Visual Source Safe (pray for me.)
Our practice is to link the project into version control through VS; in the Solution Explorer, right click on the root object -- either your one project or your solution containing several projects -- and select Add Project to Source Control. It has been a long time since my Visual Studio was configured so I don't remember the process, but that should be easy enough for you to find. I'm pretty sure you can add other versioning databases than just VSS.
With Source Safe, adding a project or solution will add the code files, the folders holding code files, and the solution and project files, but not the bin or object folders. Presumably, this is because those tend to change very frequently during development, and can be reconstructed easily by recompiling the code.
|
|
|
|
|
Gregory.Gadow wrote: I'm pretty sure you can add other versioning databases than just VSS.
If you want subversion integration in Visual Studio, AnkhSVN is one plugin that facilitates this. I personally preferred TortoiseSVN (which is an Explorer shell extension).
|
|
|
|
|
I have found VisualSVN Server (free) and AnkhSVN plugin (free) a good combination.
Free + Free = just how we like it......
Dave
Find Me On: Web| Facebook| Twitter| LinkedIn
CPRepWatcher now available as Packaged Chrome Extension, visit my articles for link.
|
|
|
|
|
This,
Ankh svn plugin for Visual Studio will handle everything for you, you just check out, commit, etc a solution and the plugin will handle everything for you.
|
|
|
|
|
He's using VS Express, plug-ins are not supported.
|
|
|
|
|
RapidSVN is a good simple rich client
ken@kasajian.com / www.kasajian.com
|
|
|
|
|
No need to filter out, you can put everything on the share directory! j/k :p
VisualSvn is great for that, it's a shame you can't use it.
In C#, you should ignore these (maybe VB.NET has more?)
- Solution.suo which contains "solution user options"
- Project/bin/ which contains your builds
- Project/obj/ which contains temporary files for your builds
Also, the typical SVN structure is to have your application files within the "trunk" sub directory. This is useful so you can have another root directory for documentation, installer files, etc. and so you can have branches and tags directories too.
On the other hand, I've just switched to "distributed version control", namely Mercurial with TortoiseHg and I strongly recommend everyione that they look into it. I won't try to sell it to you (it's free  ), but if you're changing for a version control system, it probably is the best time for you to evaluate it. Even if you don't go for it, it will help you understand the version control concept in general. And there are many advantages to Mercurial like local commits/branches and a "real" tag feature.
Here's an article I read recently (thanks to the CodeProject daily newsletter) about structuring a Git repository (it's the same as Mercurial, but it was designed by some operating system inventor or whatever  ) : http://nvie.com/posts/a-successful-git-branching-model/?[^]
|
|
|
|
|
- Project/bin/ which contains your builds
What is the general / advised approach when developing reusable components for later inclusion via SVN externals?
Currently we have, e.g.
Component x - reusable component
Application 1 - application that uses component x
Application 2 - application that uses component x
In order to get applications 1 & 2 to use component x, we include the bin\* directories in SVN and refer to them in the applications as SVN externals pointing at the bin directories.
I'm guessing from the "don't include bin" suggestion that there's a better way of doing this - any suggestions? Bearing in mind that we don't want the applications to recompile the component each time.
|
|
|
|
|
We have a folder called 'Assemblies', into which we copy the generated .dlls when they are ready for consumption. This allows us to make changes (and check them in, so we don't lose our work) without affecting the 'upstream' items. When it is ready for a new 'release', copy the completed bin files into the Assemblies folder.
Then, the upstream projects have a References folder, with an entry for each 'subsystem' that needs to be referenced which points to the Assemblies folder for the subsystem.
Bin is not stored in our source control.
(we are using TortoiseSVN)
|
|
|
|
|
I use references and set their property to "copy local" or something like that. You can reference other projects so the dll is rebuilt and imported automatically to your build directory.
For asp.net, I guess you could use the strategy of having an "assemblies" directory and set their build action to "copy to output directory", and "copy if newer". If that is not available in asp.net, you could use a post build script to copy the files from assemblies to bin. And if all else fails, I think it's possible to declare that directory as a dll search path or something in the config, but that's less than ideal because it breaks the "standard" directory structure of an asp.net site...
|
|
|
|
|
Hi
I would say, preferably the files that doesn't change everytime you re-run an unmodified program.
e.g. not files that gets generated by the compiler each time you do a clean build.
Regards,
|
|
|
|
|
I agree with the other responses - ignore obj and bin folders and .suo and.user files.
I recommend Mercurial, also called Hg, as a good source control solution. It's dead simple. You can install TortoiseHg for GUI and the Explorer integration, and VisualHg for Visual Studio integration (including VS Express?). It can sync to your own hard drive, network drive, private web or ftp, or to a free account on BitBucket. Some say it is easier than Subversion and Git, both of which I've looked into but never used. We currently use Source Safe and I'm evaluating Mercurial and love it so far. But no doubt I would love a good tar and feathering than to continue to work with and trust Source Safe.
Do not use Source Safe. Almost anything is better. I read recently that Source Safe is the most dangerous software ever written that was not intentionally designed as a virus. Let's all have a moment of silence for Gregory.Gadow having to use it.
Mike
|
|
|
|
|
We use TSVN and VisualSVN. Here is my global ignore pattern, this will prevent listing folders or files when you add them to the repo:
*/bin */obj *.bak *.*scc *.user *.suo *.webinfo bin obj *.pdb *.exe *.DCS *.zip
2 years ago we moved from SoureSafe to SVN that is why I added to ingnore the .scc file.
|
|
|
|
|
As with so many things: it depends. If you are just doing hobby projects (which it sounds like you are) then excluding the output from compiles (the obj and bin folders) is absolutely fine.
However, in a professional setting you may sometimes encounter a discipline called “configuration management”. (This is, essentially, management of the whole software lifecycle and integrates “change management”, “repository management”, “release management”, etc, into a coherent whole.) In configuration management it is common to include the final deliverables (*.exe, *.dll, etc) under version control. The reasoning being that the state of the build machine can have an impact on the final deliverable ... add a patch and the compiler might produce something subtly different. It is also common under configuration management best practices to place documentation (program specs, user guides, operations manuals, etc) under version control too.
As general advice I’d say, unless you are short of disk space, if in doubt add it in. Better to have an unnecessary file in the repository than to discover after the fact that you’ve lost the specific version of a key file.
|
|
|
|
|
Peter Trevor wrote: However, in a professional setting you may sometimes encounter a discipline called “configuration management”. (This is, essentially, management of the whole software lifecycle and integrates “change management”, “repository management”, “release management”, etc, into a coherent whole.) In configuration management it is common to include the final deliverables (*.exe, *.dll, etc) under version control.
However one would then also expect that there would be a process step(s) which is specific to building as well. And it should start with a clean extract.
Consequently one would not check in source/proj/etc files at the same time as deliverables.
Peter Trevor wrote: As general advice I’d say, unless you are short of disk space, if in doubt add it in. Better to have an unnecessary file in the repository than to discover after the fact that you’ve lost the specific version of a key file.
Better to figure out what files are actually required. It becomes obvious with a clean extract.
|
|
|
|
|
jschell wrote: However one would then also expect that there would be a process step(s) which is specific to building as well. And it should start with a clean extract.Consequently one would not check in source/proj/etc files at the same time as deliverables.
Quite correct, sorry if that wasn’t clear. Overall in SCM (software configuration management) *final* deliverables are under version control but that does not mean that those deliverables are tracked in interim stages. (Depending on the specifics of the SCM plan being used ‘candidate’ final builds may also be version controlled.) As you point out, candidate final deliverables are usually built from a clean extract (and usually on a clean build machine) after the developer has checked in his changes. I wasn’t trying to explain SCM in detail, merely make the OP aware of its existence.
jschell wrote: Better to figure out what files are actually required. It becomes obvious with a clean extract.
But if you aren’t following an SCM process it is better to err on the side of caution. Especially if (as is the case with the OP) you aren’t sure what you need to track to begin with ... you can always fine tune by dropping items over time as you gain a better understanding. It’s harder to fine tune the other way.
|
|
|
|
|
The only bin file to put in would be the .exe or any file it requires to run (.dll?).
Think of doing a build / clean before checkin, then add in the few files needed to run your app.
(My gang keeps checking in .suo files, they come out read only and screws my ability to build...)
Note .sln and .vbproj are required, they're your solution and project files. .vb is your source code. I think .resx is generated by Visual Studio...
|
|
|
|
|
CDMTJX wrote: I think .resx is generated by Visual Studio...
.resx files are resource files. They can potentially contain images, icons, strings, and other data necessary for your program. If .vb is source code then .resx is source ‘non-code’.
|
|
|
|
|
Yup, I wasn't clear... VB creates .resx during project editing, not during building. So it is required to build with, not the result of a build, and not edited by programmers (though I've been known to edit such files with C++ and C#...).
Check .resx into source control.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
