Hi,
I agree with some your comments and complaints, but some others sounds more like misunderstanding what SDK is and how it works.
[quote user="PatB"]1. All examples have .NET 4 as Target Framework set. Not 4.5.2. as necessary since Update4[/quote]
Yes, it's annoying and this problem was discussed several times. But in my opinion the solution is not so complicated.
[quote user="PatB"]Only by deleting the bugged .csproj and creating a complete new project with VS, then including the .cs resources again, i was able to get them compile with .NET 4.5.2. as target framework.[/quote]
It's too complicated to do it this way and it's not necessary. If you check csproj structure (which is not buggy, there is one bug only), you can see TargetFrameworkVersion element is not specified, but it should be, otherwise some default value is used. I have not tested it with all managed code examples, but it seems to be enough to add a proper TargetFrameworkVersion and TargetFrameworkProfile definitions into csproj file (e.g. from empty correct C# project) and it's enough. No other changes are required.
[quote user="PatB"]It seems Bentley wrote (manually?) many variables into the .csproj files (since at least my Visual Studio 2013 is not showing the variables), while these variables are not set (probably only in the Bentley dev Environment set).[/quote]
What do you mean by "many"? It's defined by Bentley that SDK and delivered tools are based Development Shell that is used to configure everything required for C++, C++/CLI and NET development. If you choice is to don't use it, it's possible, but it's your responsibility to set your environment properly.
BTW, to modify project files is quite often requirement for more complex development, because Visual Studio does not allow (there are not tools in VS) to define all features and settings in the proj files. So nothing specific for Bentley.
- MS variable: If you don't have it, why you don't define it? To reference assemblies using the variable is a perfect way how to e.g. compile code with different versions. Do you know about any simple way how to e.g. build NET project against CE Update 1, 2, 3, 4 assemblies to test you don't use class or method not available in earlier versions?
- $(MSBuildExtensionsPath) and $(MSBuildToolsVersion): They are Visual Studio macros, use Google to get more details.
- To include command table file properly, manual modification of csproj file is also required, because Visual Studio does not allow this type of configuration, despite of it's correct and supported by MSBuild.
[quote user="PatB"]The projects contain useless files.[/quote]
Why do you think they are useless? All these files are used for defined purpose(s).
[quote user="PatB"]Probably for those who want to compile in a DOS console without any debugger, adding only an inconvenient additional step instead of compiling directly from VS.[/quote]
- Probably for those who want to compile in a DOS console: What Visual Studio does? For every step it calls MSBuild that collects all parameters and starts a proper tool (compiler, linker...) with proper parameters. Everything in own shell, where the only difference is that it's not displayed by default.
- ...without any debugger: How debugging relates to compilation and linking? Regardless how managed assembly is created (manually, using bmake, using direct execution MSBuild or pushing buttton in Visual Studio (which is equal to calling MSBuild), it can be debugged the same way.
- adding only an inconvenient additional step instead of compiling directly from VS: Disagree completely. It does not add nothing, despite of you treat command prompt as inconvenient. If configured properly, NET exampels can be built directly from Visual Studio OR from dev shell. Native code examples are created to be built using bmake from development shell. They are examples only, it's completely up to you how you will create your own projects.
[quote user="PatB"]As the included readme states, i would also have to start first MicroStationDeveloperShell.bat, which is not working right away and needs several parameters set that are nowhere explained (see next point).[/quote]
I agree to set up dev shell is not the most inuitive, especially if you are experienced with Windows approach only and not e.g. with multiplatform or some other dev tools environment, where configuring the shell is a standard part of projects. But it's written in MicroStationDeveloperShell.bat clearly how paramaters should be defined.
[quote user="PatB"]People usually use shortcuts on a desktop or a file manager to start stuff and only rarely use a console nowadays ;-)[/quote]
Yes, if you develop for Windows only, using only tools available in Visual Studio and no external libs or specific languages, an approach "to use mouse only and click click click" can be used. And all member in the team have to have completely the same configuration, no differences e.g. in assembly path. But for example my experience is very different, for last several years I have no project (talking not about MicroStation apps only) without very own configuration of shell, compiled using different libs versions on different computers.
If you know Windows shell commands (no powerfull but more complex PowerShell or Linux shell is required), everything can be configured to be very close to "push the button". It's only about configuration and customization.
[quote user="PatB"]I think a developement environment in a console and based on batch files is not up to date anymore.[/quote]
If you think it's obsolete, can you provide a solution or ideas for automated builds started by Git events, testing against different libs versions and supporting colleagues in team with different configurations (e.g. not enough space on C, so everything installed on D)? In last few years I spent quite a lot of time to find a best way (balanced between flexibility and complexity) to maintain projects in international teams. I also learned a lot from other people (more experienced than me), but really looking forward to learn more as this topic is challenging.
[quote user="PatB"]Only by opening the batch file, you notice that it needs 2 (optional 3) parameter to work. A very inconvenient way if someone just wants to compile and test one of the examples right away.[/quote]
As I wrote, I agree it's not intuitive and user friendly for the first sight. Especially for people without classic C/C++ development based on correctly configured shell ... how Linux, some parts of MacOS and also multiplatform open source on Windows are built. But when the configuration is done, it works for everything ... and MicroStation development is native C++ code primarily. And you can create your projects without the dev shell, especially if you want to use NET only and not native code.
[quote user="PatB"]I think VS example projects should not rely on some batch based console environment.[/quote]
- NET examples does not realy on any console, only on MS variable, that can be defined directly in Windows.
- Native code examples have to compiled using development shell, because make files do a lot of things, test environemt, call a proper tools etc.
I don't quite understand this complain, because whatever SDK or API I will use, there are alwyas some prerequisities and requirements. And to properly start a shell using 2 parameters is, comparing to some other tools, minimum effort. And anybody skilled enough can leave dev shell and to build own projects in own way, because at the end it's "only" about correct configuration of C++ and C# compilers and linkers, no magic.
Summary:
- NET examples: 2 actions required:
- It's reported and known issue that SDK NET examples in Update 4 have wrongly defined (better to say undefined) Target NET Framework. To correct it, to add necessary XML element definitions (2 lines) is required.
- To define MS variable is required by NET examples, but it can be replaced or defined in Windows. No shell is required, Visual Studio is enough.
- Native code examples:
- Development shell is required. To start it, 2 parameters, no more, have to be defined, as described in bat file.
- Bmake is the only officially supported tool to compile native code for MicroStation, but it's possible to create VS project that calls bmake insted of own make file, so an experience and workflow is the same.
- Using command prompt and to call batch files or MSBuild files is very often used, especially if automated building process is implemented. It's used even if connected to Visual Studio Team Services system.
With regards,
Jan