Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/SharpKit/SharpKit/wiki/Path-changes below:

Path changes · SharpKit/SharpKit Wiki · GitHub

Because we went open source, we needed to change the installer, release workflow and other stuff. In this step, we decided to change some file locations.

In short

• The skc5.exe compiler is now stored in C:\Program Files(x86)\SharpKit\5\skc5.exe.
• C:\Windows\Microsoft.NET\Framework\v4.0.30319\SharpKit\5 is a symbolic link to C:\Program Files(x86)\SharpKit\5
• Libraries moved to C:\Program Files(x86)\SharpKit\5\Defs

The background

Lets assume some principial facts:

• SharpKit is not a system component. It's a third party compoment. Third party compoments should not installed into a system dir (C:\Windows....).
• Third party compoments have to be placed in C:\Program Files (x86)
• We want to follow the KISS princip (keep it simple stupid)
• Even if following the KISS way, the same (binary?) file or directories should never exists/copied twice in the file system.
• If we create an project on windows, we want to use it on unix with less manually modifications as possible.
• We want backward compatibility.

The modifications in detail

• In the history, we copied the compiler in C:\Windows\Microsoft.NET\Framework\v4.0.30319\SharpKit\5 and C:\Windows\Microsoft.NET\Framework\v3.5\SharpKit\5 (twice). We put the Definition assemblies into C:\Program Files(x86)\SharpKit\5.

• Now the compiler is stored in C:\Program Files(x86)\SharpKit\5, and C:\Windows\Microsoft.NET\Framework\v4.0.30319\SharpKit\5 has a symlink to it.

• When adding a definition assembly, it will have a path like C:\Program Files(x86)\SharpKit\5\Defs or ..\..\..\..\..\Program Files(x86)\SharpKit\5\Defs. When you open this project in unix, monodevelop will not find the assemblies.

• There exists an $(MSBuildProgramFiles32) property, but it is not supported on unix. The only usable property would be $(MSBuildBinPath). This refers to C:\Windows\Microsoft.NET\Framework\v4.0.30319\ (windows) or /usr/lib/mono/4.0/ (unix).

• Because the def-directory is now a child folder of the skc5.exe directory, we can simply access it: $(MSBuildBinPath)\SharpKit\5\Defs\Javascript.dll

• Of cousrse, you need to modify this path manually in the csproj-file:

<HintPath>$(MSBuildBinPath)\SharpKit\5\Defs\SharpKit.JavaScript.dll</HintPath>

But after that, we can open the project on windows and unix. Of course, you can provide custom target files and use a fixed directory structure. But this follows not the KISS way. For example you can now simple create a sharpkit project on windows, publish it on github. Another unix developer can get the sources and can directly compile it without having the source or the sharpkit references on a forced location, and no reference path changes are needed.

• We did not put the skc5.exe into C:\Program Files(x86)\SharpKit\5\bin (separate bin folder) because we want backward compatibility. With an seperate bin-folder, we need to use $(MSBuildBinPath)\SharpKit\5\bin that will require a manual one time modification. I would prefer the one-time modification, but we want to keep it as backward compatible as possible. On the other hand, we could link directly to the bin-folder, but than have to symblink the Defs-folder into bin. The directory structure will be very confusing than.

Optimizations in the future

• In the moment, C:\Windows\Microsoft.NET\Framework\v4.0.30319\SharpKit\5 points to C:\Program Files(x86)\SharpKit\5. In the future it should point to C:\Program Files(x86)\SharpKit\5\NET 4.0 / NET 4.5
• But maybe the better way is to have an separate sharpkit version for that. For example when C# 5.0 will be released, we should change the sharpkit major version, so you can use $(MSBuildBinPath)\SharpKit\6.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4