Да, за исключением .settings папки. Фиксация других файлов работает хорошо на нас. Существует подобный вопрос здесь .
См. также Может ли огромная существующая приложение будет перенесено в интернет? Как?
Извините, нет хороших решений, только менее плохие....
Во-первых, поскольку вы уже разрабатываете для windows, я предполагаю, что вы привыкли использовать средства разработки Microsoft, я бы не дал такого же ответа для настольного приложения, которое поставляется с unix (или Mac).
Некоторые случайные мысли и указатели.
(К сожалению, я не знаю совпадений с Python, однако, если у вас еще нет в нем навыков, я бы сказал, прилипнуть к стеку Microsoft, так как вы уже знаете отладчик Microsoft и т.д.)
(Я думаю о переносе сложных приложений в веб как о очень большой боли , лучше избегать боли, когда это возможно, однако иногда вам не дают возможности и просто нужно свести к минимуму боль . Если вы никогда не работали с большими приложениями, которые находятся в процессе (обычно много лет работы) переноса в web, вы просто не знаете, за что вы себя выдаете!)
3- Python - решение.
Сделайте Интерфейс точки входа sigle в Python, который принимает только имя функции и список параметров для передачи самой функции. Вам сразу будет с чем начать экспериментировать и посмотреть, какие функции DLL действительно необходимы для первого функционального веб-прототипа.
Заглушка для одного функционального модуля
#include <Python.h>
#include <string.h>
int int_function(int a){
return a +=1;
}
static PyObject *
exec_lib(PyObject *self, PyObject *args)
{
char *fun_name;
PyObject *func_name = PyTuple_GetSlice(args, 0,1);
PyObject *res;
if (!PyArg_ParseTuple(func_name, "s", &fun_name))
return NULL;
Py_DECREF(func_name);
if (strncmp("int_function", fun_name, 1024) == 0)
{
int i;
PyObject *fun_args = PyTuple_GetSlice(args, 1,20);
if (!PyArg_ParseTuple(fun_args, "i", &i))
return NULL;
Py_DECREF(fun_args);
res = Py_BuildValue( "i", int_function(i));
} else {
Py_INCREF(Py_None);
res = Py_None;
}
return res;
}
PyMethodDef methods[] = {
{"exec_lib", exec_lib, METH_VARARGS, " Returns"},
{NULL, NULL, 0, NULL}
};
PyMODINIT_FUNC
initlibwrap()
{
(void) Py_InitModule("libwrap", methods);
}
может быть скомпилирована с помощью файла setup.py
from distutils.core import setup, Extension
setup(name = "libwrap",
version = "1.0",
ext_modules = [Extension("libwrap", ["my_library_wrap.cpp"])])
и используется в простом веб-сервере, таком как
from BaseHTTPServer import BaseHTTPRequestHandler, HTTPServer
import libwrap
def int_function(value):
return libwrap.exec_lib("int_function", value)
print int_function(10)
class MyHandler(BaseHTTPRequestHandler):
def do_GET(self):
self.send_response(200)
value = 'Error'
try:
value = int_function()
except:
import traceback
traceback.print_stack()
self.wfile.write(value)
def main():
try:
ip ='localhost'
port = 8080
server = HTTPServer((ip,port), MyHandler)
server.serve_forever()
except KeyboardInterrupt:
server.socket.close()
if __name__ == '__main__':
main()
Я бы сказал, что вариант 2 - лучший вариант. При условии, что вы создаете интерфейс в .Net для своей DLL, чтобы убедиться, что вы правильно освобождаете свою память и т.д., когда это необходимо, я не вижу проблемы. Если вы можете повторно использовать бизнес-логику в своей DLL и в основном выполнять веб-вызовы в своей DLL, тогда отлично.
Меня беспокоит только API вашей DLL. Очевидно, что ASP.Net - это многопользовательское многопоточное приложение. Разработан ли ваш API для этого, учитывая, что в большинстве приложений Windows Forms им управляет только один пользователь (представьте, что каждая форма в вашем приложении может быть открыта более чем одним пользователем одновременно).
Если вы можете повторно использовать бизнес-логику в своей DLL и в основном выполнять веб-вызовы в своей DLL, тогда отлично.Меня беспокоит только API вашей DLL. Очевидно, что ASP.Net - это многопользовательское многопоточное приложение. Разработан ли ваш API с учетом этого, учитывая, что в большинстве приложений Windows Forms им управляет только один пользователь (представьте, что каждая форма в вашем приложении может быть открыта более чем одним пользователем одновременно).
Если вы можете повторно использовать бизнес-логику в своей DLL и в основном выполнять веб-вызовы в своей DLL, тогда отлично.Меня беспокоит только API вашей DLL. Очевидно, что ASP.Net - это многопользовательское многопоточное приложение. Разработан ли ваш API с учетом этого, учитывая, что в большинстве приложений Windows Forms им управляет только один пользователь (представьте, что каждая форма в вашем приложении может быть открыта более чем одним пользователем одновременно).
Поскольку никто не упомянул об этом, как насчет Wt .
Если вы не ищете пользовательский интерфейс на основе проводника, существует множество библиотек C ++ для расширения локального приложения до веб-приложения, POCO - одна из них. Если вы придерживаетесь платформы Windows, WWSAPI действительно хорош для разработчиков C / C ++.