Background:
I work for a company that sells chips and we provide an SDK that goes along with it.
So far, the creation SDK step has been pretty manual and it's created a lot of churn between the SDK providers and the SDK users.
I want to get the SDK generation into the workflow so that everybody (including the SDK providers) uses the SDK to build their applications and the SDK is automatically generated from the original source.
In basic workflow, I want
SDK Provider view:
/application (checked in)
/source (checked in)
/sdk (not checked in)
/build (not checked in)
SDK User view:
/application (checked in)
/sdk (checked in)
/build (not checked in)
When the SDK provider starts work, configure/build would convert some of /source to libraries and deposit them into the /sdk directory along with other files (headers, interface .cpp files, CMake files, etc)
Then an application would configure w/the SDK directory and build.
When satisfied, we'd commit/push/tag, and automate the build of the SDK and commit to the SDK subrepo, etc. Where an SDK user could clone and do the same thing as the provider, except without the /source directory.
Changes to the /source directory should rebuild/copy whatever is appropriate to the /sdk directory, and direct changes to the /sdk directory would be discarded/disallowed.
I'm assuming I want to make use of the "install" stuff in CMake, but I'm not exactly sure how to get the dependencies correct.
Also, how does the SDK provider, who has no /build or /sdk directories at the beginning get started? I'm guessing trying FindPackage() for /sdk and then findpackage for /source (or something like that)
Anyways, any pointers would be appreciated. It's not a typical flow so I'm having a hard time finding stuff on google that's exactly on point.
Related
My VStudio is 2019 Community, the application is an old VB Windows/Forms app being brought forward from .Net-3.5-ish to .Net-5.
Under .Net-4.8 or earlier, using the namespace System.Deployment.Application, one could access ApplicationDeployment.DataDirectory to locate that artificially-generated directory in \Users\Username\AppData\Local\Apps\2.0\... that a 1-click installation would create and populate with data files from the Project Build/Publish.
Under .Net-5, I believe that particular set of functions has been taken out - yet the ClickOnce installer still places Data files there. How do I programmatically locate that directory? The Application Path can be located from System.AppContext.BaseDirectory, but that doesn't help in locating the data.
This app, an old bit of VB code, has a large number of application data files that need to be installed along with the code. As there are more than 40 of them, we've kept them in their own \Data directory, which is included in the Project, is under Git control to keep their versions aligned with their code...
In an uninstalled app, we could keep this \Data directory adjacent to the executable, and find it easily at runtime: but with a ClickOnce installed app, that falls apart. In the Publish configuration, all the data files are identified, with Group=Required, Publish Status=DataFile.
Can I either:
Easily configure the 1-click installer to place our \Data directory and its contents into one of the standard \Local\Appname or \Roaming\Appname directories that seem to also get created, but left empty? Those can easily be located at runtime.
Easily construct at runtime the path to that obscure data directory that 1-click normally creates and uses for data?
Cheers, and Thanks! Bob
I have set up a minecraft mod in eclipse before, only it was in 1.12.2. I installed the ´src´ forge for 1.12.2, but there is no src option for 1.14.4. I have heard that the code for minecraft was changed, so modding minecraft in 1.14.4 is different to modding 1.12.2 minecraft. Can somebody please help?
Go here: https://files.minecraftforge.net/
Click this:
You may alternatively download the recommended build. Forge for 1.14 is still under active development and some features may not be present in the recommended build.
Create a folder where you would like your workspace to live, eg workspace (I name it with the Forge version number, personally). Inside it create another folder, I name it project, but the name isn't important, just that having this extra layer will make things play nice (I will use these names in this answer only to make it clear which folder I'm talking about).
Extract the downloaded zip into the project folder
Shift-right click on the project folder and "open power shell here."
Run the two commands listed in the readme: ./gradlew genEclipseRuns and ./gradlew eclipse (note: do not do steps 4 and 5 of the readme, they are outdated)
Open eclipse, switch workspace (File -> Switch Workspace -> Other) to the workspace folder. Eclipse will restart.
File -> Import...
General -> Existing projects into workspace
Where it says "select root directory" point it at the project folder and check "search for nested projects"
Pretty much hit next until its done (or you can hit Finish right away).
This should leave you with a Package Explorer that looks like this:
Your code and assets will go inside src/main/java and src/main/resources (note that assets will contain both "assets" and "data" folders, for client-side assets and datapack assets respectively). Minecraft read-only source is available in the Project and External Dependencies group, note that many of the vanilla assets (including data packs) are found in the client-extra.jar file.
Lastly:
Find the src/main/resources/META-INF/mods.toml file
Edit as necessary with your mod ID and other information. The file is well commented.
Any further issues should be directed to the Modder Support forum.
We have multiple developers working on a shared project through dropbox. Each time one of the developers saves a file, the other developers get the following message:
"Project Files Changed
Project components were changed externally and cannot be reloaded:
ToolWindowManager
Would you like to reload project?"
How can each person have their own settings in a shared project so this is not a problem?
You should use VCS (Version control systems) as for example git, and ignore the IDE configuration files (.gitignore), so you can avoid the conflicts with the configuration files
Despite a successful build, no modules will load. The Browse menu is empty (except for Assets) and custom modules in the Configuration menu are missing.
After downloading the most recent build from our repository, I followed all steps in the "Source Code Getting Started" page. It has been a few months since looking at the VC documentation, and it looks like it has been updated. I recall an extra step after creating the Assets virtual folder in IIS that isn't there now. Is there perhaps a step here that is missing since the docs update?
Fwiw, the build deployed in our QA environment is fine. This is the same code, but I am trying to run locally and am having no luck with modules.
Virtual folder for Modules is optional in IIS and this step was skipped in the updated docs. But adjusting permissions in needed: "Open properties for vc-platform\VirtoCommerce.Platform.Web\Modules (create this folder if not exsist) folder and give permission Modify to IIS_IUSRS user group as shown above."
I have multiple websites which use /wwwroot/assets folder (html theme, css and javascript files) to load the static content.
Currently I am copying assets folder in each site. All of my projects are sitting under a common parent directory.
I don't want to copy the /wwwroot/assets folder into each website. Is there a way to share one assets folder between all sites. May be by providing a direct file system path or something?
At the moment it's not clear from the documentation what sorts of values the webroot key in the project.json file will accept, but so far it would appear that Visual Studio doesn't care for very complicated paths. For example, setting the value to ../wwwroot causes the entry to disappear in the Solution Explorer.
If you look at the kpm code that bundles your project up for deployment, it appears to combine your project's directory with whatever is stored in the wwwroot key, so even though Visual Studio may not understand it, relative paths appear to be supported. Using kpm bundle from the command line confirms this, and a directory above src bundles correctly when using a relative path.
Depending on your particular needs, there is one way that should work that makes kpm and Visual Studio happy, but it will depend on your build environment as to whether that is a good option for you.
Windows, OSX, and Linux all support creating symbolic links for directories, which would allow you to have your assets directory in one location in the filesystem and then create links to it elsewhere. For example, if you had assets in /projects/shared/assets, you could create a link in both of your other projects (e.g. /projects/project1/src/wwwroot/assets) that point to the "real" location.
In Windows, the command would might something like this
mklink /j "C:\link\to\create" "C:\path\to\assets"
So if you did
mklink /j "C:\source\shared\assets" "C:\source\project1\src\wwwroot\assets"
project1 would appear to have an assets directory inside of wwwroot and the build process would be happy since it would appear to each project that the files were local. One thing to note here is that Windows supports a number of different sorts of links. /j specifically creates a junction rather than a true symbolic link. The differences are a bit subtle, but this is a good description of the differences. It is enough to know that if you're working locally, the /j command doesn't require administrative rights and Visual Studio and kpm will both be happy.
In OSX and Linux, the command is similar:
ln -s /link/to/create /path/to/assets
and like Windows, they support different sorts of links.
In any case, under the right circumstances, this might work well without needing any special support from the new ASP.NET project structure, but it would be nice to eventually have that as well.